<jernej>
I know, I wish Allwinner would release docs for HDMI
<jernej>
but it seems that they want to hide sources even more
<jernej>
for example, sun8iw6 HDMI source is even more obfuscated, they transformed binary blob to byte array
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
<jelle>
:S
<jernej>
and they are calling functions inside this byte array
<jernej>
but funny thing is, when FriendlyARM released their H3 kernel sources
<jernej>
this file is nice C code...
<MoeIcenowy>
jernej: Thanks!
<MoeIcenowy>
jernej: it't the usual things to happen on Allwinner SoCs
<MoeIcenowy>
in the former A23/33 SDKs
<MoeIcenowy>
the gsl_point_id library of gslx680new driver is blob
<MoeIcenowy>
but in A64
<MoeIcenowy>
it's source code
<MoeIcenowy>
(although ugly, but not obfuscated
<jernej>
ok, I didn't mean nice in nicely formated, but as in readable :)
<jernej>
can someone explain to me if it is ok to use "confidential" datasheets found on forums, etc. to write drivers? For example, H3 datasheet is still marked as confidential and Allwinner didn't publish it yet...
<MoeIcenowy>
In the allwinner things, datasheet means nothing
<MoeIcenowy>
for driver you need user manual
<MoeIcenowy>
and H3 user manual is not even leaked.
<MoeIcenowy>
jernej: But I will soon try to use the H3 HDMI out-of-tree semi-mainlined driver on A64
<MoeIcenowy>
KotCzarny: Theoritically licenseless code in a kernel source tree can be seen as copyleft...
<MoeIcenowy>
But we don't dare to assert it
ricardocrudo has joined #linux-sunxi
<KotCzarny>
they are ignoring gpl totally, so what could be the consequence of treating it as such?
<KotCzarny>
who could make any legal action in such case?
<KotCzarny>
arm?
<MoeIcenowy>
Everyone cannot do things
bonbons has joined #linux-sunxi
Netlynx has joined #linux-sunxi
apritzel has joined #linux-sunxi
dearfibonacci has quit [Quit: Leaving]
paulk-collins has joined #linux-sunxi
<jernej>
KotCzarny: I read that GPL licence can be enforced only by the owner of the code. In this case I'm not sure who that is.
dearfibonacci has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
dearfibonacci has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
|Jeroen| has quit [Quit: dada]
leberus has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
montjoie has quit [Ping timeout: 244 seconds]
montjoie has joined #linux-sunxi
IgorPec9 has joined #linux-sunxi
<MoeIcenowy>
apritzel: If the A64 SPL is mainlined
<MoeIcenowy>
how can we place ATF?
<MoeIcenowy>
(As I remembered someone have succeeded to apply the H3 dram code to A64
<apritzel>
MoeIcenowy: I have some code to load a U-Boot FIT image from SPL
<apritzel>
worked well when I tried it
<MoeIcenowy>
apritzel: where's them?
<apritzel>
on my hard disk ;-)
<MoeIcenowy>
apritzel: with a modified mainline SPL?
<MoeIcenowy>
(I remembered you have a SPL with libdram
<apritzel>
the version I have tried is with libdram SPL still
<apritzel>
but the FIT loading part is totally independent from that
<apritzel>
so should work well with jemk's DRAM code as well
<MoeIcenowy>
yes
<apritzel>
I used mkimage for combine U-Boot and ATF into a FIT image and put that right behind the SPL on a SD card
<apritzel>
and that worked like a charm
<apritzel>
I also added a kernel and initrd into the same FIT image and put that on a 16MB NOR flash
<apritzel>
and could boot from it as well
IgorPec10 has joined #linux-sunxi
IgorPec9 has quit [Ping timeout: 258 seconds]
kaspter has quit [Ping timeout: 265 seconds]
<MoeIcenowy>
apritzel: oh
<MoeIcenowy>
can you just push these code?
IgorPec10 has quit [Ping timeout: 240 seconds]
dearfibonacci has joined #linux-sunxi
<montjoie>
apritzel: successsfully tested your A64 patchs with emac, do you want some Tested-By ?
IgorPec has joined #linux-sunxi
<apritzel>
montjoie: sure, thanks!
<apritzel>
montjoie: btw: I was seeing that with the "upstream" A64 firmware we end up with a 200 MHz AHB2 clock, whereas the recommended speed is 300 MHz (the BSP package uses this as well)
<apritzel>
AHB2 is used by the EMAC, so there is some hope for faster transfer rates ...
|Jeroen| has joined #linux-sunxi
<MoeIcenowy>
apritzel: how will you implement AXP support in ATF?
<MoeIcenowy>
(AXP contains 3 power sources, include one battery fuel gauge, and regulators, and a key, and some GPIOs
<apritzel>
battery fuel gauge sounds like a sensor to me
<apritzel>
what are the GPIOs used for?
<apritzel>
also I am not sure we need to expose everything that the AXP provides to Linux
<MoeIcenowy>
apritzel: GPIOs can be regulators
<MoeIcenowy>
or to power LEDs
<MoeIcenowy>
(for example, CHIP uses a axp gpio to power a led
<BenG83>
the charge LED output needs a bit set to one
<MoeIcenowy>
yes
<MoeIcenowy>
apritzel: A64 tablets may use many of the functions.
<BenG83>
tablets might have a well defined battery, but SBCs with battery connectors mayb have different batteries
<KotCzarny>
apritzel, ok, what was the question again?
<MoeIcenowy>
(although I think no application will use that
<MoeIcenowy>
tablets might have a well defined battery, but SBCs with battery connectors mayb have different batteries
<MoeIcenowy>
I agree with this sentence
<MoeIcenowy>
(So I wanted to push a axp20x_battery driver which uses the default OCV shipped in AXP
<apritzel>
the question is: why do we need to expose all of those gory details to Linux?
<MoeIcenowy>
apritzel: At least all the functions will be needed in some way.
<apritzel>
if someone connects a charger, I expect the battery to be charged
<MoeIcenowy>
(except the NVRAM, which is too small
<apritzel>
why should Linux play a role in here?
<MoeIcenowy>
apritzel: but I will be worried
<MoeIcenowy>
if I cannot know the battery value
<KotCzarny>
also, axp209 battery charging logic is BRAIN DEAD
<apritzel>
you can know the value: it's a sensor
<apritzel>
SCPI provides a sensor interface
<KotCzarny>
my bpi-r1 is constantly charging the battery
<KotCzarny>
with low amp, but still, its sure way to kill the battery
<MoeIcenowy>
apritzel: it can deal with all kinds of sensor?
<apritzel>
I will provide a sample implementation for the THS temperature sensor later
<MoeIcenowy>
apritzel: and can we directly make some of the sensors to be a power supply driver?
<BenG83>
the BSP kernel for A64 uses some dts entries to define all the charger settings and battery parameters atm, but I only logged on charge/discharge cycle so far, not sure if it works properly
mosajjal has joined #linux-sunxi
<MoeIcenowy>
(and we will need to feed the OCV value to the chip, when the battery is fixed
<MoeIcenowy>
(will we just hardcode the OCV value into ATF?
<MoeIcenowy>
(Thus we will need an ATF per tablet
dearfibonacci has quit [Quit: Leaving]
<wens>
MoeIcenowy: scpi sensors has an hwmon driver
<MoeIcenowy>
wens: yes... hwmon driver is suitable for a thermal sensor
<MoeIcenowy>
but I don't think it's suitable for a bettery
<MoeIcenowy>
battery
<BenG83>
the AXP and the battery probably should be abstracted like a normal laptop smart battery, it´s just a special case where they don´t form a single unit and some more parameters are needed?
<MoeIcenowy>
BenG83: in laptops, battery is dealt with ACPI
<MoeIcenowy>
but we cannot implement an ACPI now
dearfibonacci has joined #linux-sunxi
<BenG83>
mmh
<MoeIcenowy>
SCPI is now only a Juno-oriented interface...
<MoeIcenowy>
it can suite a ITX-sized motherboard
<MoeIcenowy>
but I cannot imagine it will suite a Q8 tablet
<apritzel>
SCPI defines temperate, voltage, current, power, energy classes for sensors
<apritzel>
so for reading those values, we should be covered
<MoeIcenowy>
apritzel: yes... regulators, power supply can now be supplied with SCPI
<MoeIcenowy>
how about GPIOs (or we may need a pinctrl, as one GPIO is muxed with LDO, and another is muxed with a ADC)
<MoeIcenowy>
and PEK (which can have a keyboard driver)
popolon has joined #linux-sunxi
<apritzel>
if those GPIO are used for controlling power domains, we could use either SCPI's regulator or power domain abstraction
<MoeIcenowy>
apritzel: the board vendor can control the GPIOs' usage
<MoeIcenowy>
they can vary among boards
petr has quit [Remote host closed the connection]
<MoeIcenowy>
and the Power LED can be also used as a generic LDE
<MoeIcenowy>
LED
<BenG83>
I enabled the charger led on one of my Pine64 images by hacking a register write in the ATF
<BenG83>
Android images already had that somehow
<BenG83>
seems to work according to the datasheet
<MoeIcenowy>
BenG83: how do you wire the LED?
<MoeIcenowy>
(I now found that a dt is much more flexible than an ATF...
<MoeIcenowy>
(for dt we can have overlays
petr has joined #linux-sunxi
<BenG83>
LED is already wired on the Pine board
<MoeIcenowy>
(but for ATF we can only have hardcoded logics... and it may vary from board to board...
<MoeIcenowy>
BenG83: which one?
<MoeIcenowy>
the red one?
<BenG83>
no that one is fixed to PSOUT
<MoeIcenowy>
(My Pine do not have a battery
<BenG83>
the two free led spots
<BenG83>
one is wired to the CHRGLED of the PMIC
<BenG83>
and the other is just PL7 on the A64
<MoeIcenowy>
PL7... so it cannot be used in mainline now...
<apritzel>
MoeIcenowy: if those GPIOs are board specific, then controlling it in firmware sounds like a good fit
<BenG83>
CHGLED is a dedicated LED control output
<MoeIcenowy>
apritzel: they can be not board specific
<MoeIcenowy>
for example
<MoeIcenowy>
I have no battery for my Pine
<MoeIcenowy>
then I can use the CHGLED as a generic LED
<MoeIcenowy>
which can flash as heartbeat, mmc0 indicator, wifi indicator, etc
<MoeIcenowy>
apritzel: do you have axp803 datasheet? see reg 0x32
<MoeIcenowy>
bit3 is called "CHGLED pin control", it can switch the LED from two modes: one is manual controlling, the other is automatic controlling by charger
<MoeIcenowy>
for BenG83 he may need a automatically controlled CHGLED as he has a battery
<MoeIcenowy>
for me I need a manual controlled LED as I have no battery
perr has quit [Quit: Leaving]
<apritzel>
MoeIcenowy: frankly: if I have to trade control of a single LED for a well defined firmware interface, I am happy to abandon this specific LED usage
<apritzel>
or find another firmware interface to control it
<apritzel>
for instance we can have a vendor specific smc call for the LED, if you like
<MoeIcenowy>
apritzel: but I think the firmware interface is not so well-defined
<MoeIcenowy>
It contains still too many vendor-specified things
<MoeIcenowy>
(Or the full ARM platform is not so well-defined
<apritzel>
so let's change that ;-)
<MoeIcenowy>
(To be honest, I think an well defined interface which cannot support a full system is meaning
<MoeIcenowy>
(So I think we should either choose a fully kernel-side thing, or an ACPI-based solution...
<dearfibonacci>
Hello. Anyone here experienced with A20 olimex Micro arm pc?
jernej has quit [Ping timeout: 240 seconds]
<apritzel>
apritzel: frankly, most of the ATF functionality we have at the moment is about the SoC
<apritzel>
MoeIcenowy: I meant ;-)
<MoeIcenowy>
yes...
<MoeIcenowy>
maybe we should mean for the "A64 + AXP803" combine
<apritzel>
and you will still need a board specific U-Boot port anyway
<apritzel>
afaik A64 and AXP803 are closely coupled
<MoeIcenowy>
yes
<apritzel>
so chances are we will always see both together
<MoeIcenowy>
we won't expect an A64 without AXP803
<KotCzarny>
or just ignore all those things and just let common driver act as a glue for all axp chips?
<MoeIcenowy>
just like we cannot see an A33 without AXP233
<wens>
shit always happens, like some vendor did an A80 board without the normal PMICs...
<MoeIcenowy>
wens: oh such shits
<hp197>
^ could be abbrevated to: "shit always happens, like the A80"
<wens>
hp197: sad, but true
<wens>
hp197: cpufreq is a separate item
<hp197>
ok, then we might need to add it now the driver is changed to cpufreq-dt
<apritzel>
KotCzarny: that's the idea of putting AXP support into ATF: on the Linux side it's a bunch of SCPI regulators
<apritzel>
KotCzarny: all described in DT
dearfibonacci has quit [Quit: Leaving]
<hp197>
Last weekend I couldn't get it running out of the box on A20 - 4.8.0
dearfibonacci has joined #linux-sunxi
<wens>
apritzel: so we just need some stable numbering between ATF and whatever DT consumer?
<MoeIcenowy>
wens: nope, dt can work in older versions
<MoeIcenowy>
without kernel change
<hp197>
apritzel: Do you have time to fire up a A20 and confirm broken cpufreq on 4.8?
<MoeIcenowy>
if we have really no newer IP cores
<MoeIcenowy>
but currently
<MoeIcenowy>
all allwinner SoCs come with slightly changed IP cores
<apritzel>
wens: actually not even a stable numbering
<apritzel>
as long as the DT describes what ATF provides
<MoeIcenowy>
and things like USB PHY and MMC is worst
<apritzel>
which could be achieved by letting ATF modify the DT
<MoeIcenowy>
(maybe Display is also a bad thing... mripard cannot not even make sun4i-drm work on sun8iw5
<MoeIcenowy>
now
<MoeIcenowy>
work correctly *
<wens>
apritzel: that sounds complicated
<apritzel>
wens: not if ATF (or firmware in general) actually provides the DT
orly_owl has quit [Quit: leaving]
<apritzel>
as it's actually meant to be
<apritzel>
this "the .dts live in the kernel tree" was and is a kludge
<apritzel>
to have some reliable place to store them and to avoid vendors going astray with their bindings
<apritzel>
some vendors actually don't update their DTs in the kernel tree, but just in the firmware
<MoeIcenowy>
yes, the DT can be provided by not the kernel but a good vendor
<apritzel>
which is fine as long as it still works
<MoeIcenowy>
apritzel: allwinner is also an example for a dt-in-firmware ;-)
<apritzel>
MoeIcenowy: You mean in the BSP U-Boot?
<apritzel>
I actually like that approach
<MoeIcenowy>
apritzel: yes
orly_owl has joined #linux-sunxi
<MoeIcenowy>
but the embedded dt is a sh*t
<apritzel>
only that they totally destroyed the idea by using non-standard bindings
<MoeIcenowy>
apritzel: yes
<apritzel>
which is broken by design
<MoeIcenowy>
Allwinner now cares only about Android.
<MoeIcenowy>
withoug longsleep, I will think we cannot even get fully-usable BSP Linux images
<apritzel>
oh, isn't Android and Linux the same? ;-)
<BenG83>
I just ran an Android image on longsleep´s kernel, thanks to jonsmirl
<longsleep>
without me what?
<longsleep>
well i am here, but everything i do/did is freely available to everyone and only based on publicly available stuff
<longsleep>
so everyone can replicate everything :)
<MoeIcenowy>
longsleep: I think without you Linux on Pine64 will become a disaster
<MoeIcenowy>
longsleep: but you did it.
<MoeIcenowy>
this kind of things should be done by Allwinner or Pine.
<MoeIcenowy>
but they're both sh*t vendors
<longsleep>
MoeIcenowy: well i am fairly certain that someone else would have created working images if i hadn't done it - i just came first
<MoeIcenowy>
but we should admit that Allwinner is a vendor which did little
<MoeIcenowy>
makes all of us OEM for ourselve
<apritzel>
I think the big mistake was to advertise Linux support on Pine64
<MoeIcenowy>
ourselves
<apritzel>
or A64 in general
<apritzel>
when there really wasn't any
<longsleep>
apritzel: yes
<BenG83>
they overdid the marketing campaign for the Pine by a long stretch
<MoeIcenowy>
apritzel: yes
<apritzel>
I agree that longsleep saved Pine64's ass ;-)
<BenG83>
^
<longsleep>
well i only wanted the hardware in any case, and works pretty awesome for exactly the purpose i wanted it in the first place (compiling armhf and arm64)
<MoeIcenowy>
and now apritzel is trying to become another vendor for A64
<MoeIcenowy>
(not only apritzel
<MoeIcenowy>
(all the coders in linux-sunxi are all vendor workers
<apritzel>
MoeIcenowy: Imagine: there was a time when vendors didn't care about Linux support at all ...
<apritzel>
apparently Allwinner does not do at the moment
<BenG83>
but my impression is that linux-sunxi is pretty unique for mainlining efforts for ARM SoC?
<apritzel>
so the community takes over
<BenG83>
I was looking at linux-exynos and others and they seemed pretty dead
<MoeIcenowy>
BenG83: the real vendor replaced the community vendor
<BenG83>
ther was something happening with Rockchip iirc
<MoeIcenowy>
BenG83: rockchip coders are now active in LAMKL
<MoeIcenowy>
LAKML
<MoeIcenowy>
have you seen anyone with @allwinnertech.com in LAKML?
<wens>
i don't really believe in the "new DTs work for older kernels" thing
<wens>
at least not until the platform is mature with all major drivers
<huawei>
BenG83, linux-exynos seemed dead because samsung did everything =_=|||
<BenG83>
that sounds like a good thing then?
<MoeIcenowy>
'linux-exynos seemed dead because samsung did everything' +1
<BenG83>
btw does anyone have a Pine64 with GbE issues?
<Wizzup>
Well, that's not exactly true
<Wizzup>
There are still some things to do be done, but many things are indeed already done
<BenG83>
I got 4 boards now and I can´t replicated any of the reported issues
<BenG83>
*replicate
<Wizzup>
The wiki is in a sore state though (linux-exynos)
<Wizzup>
back later :)
<hp197>
My bet is that Allwinner doesnt care much atm
<hp197>
They can say their cpu supports linux (because of 3.x kernel)
<hp197>
and they dont have to invest into mainline
<apritzel>
hp197: they only care about Android, because that's their market
<hp197>
apritzel: true, but eventually they still need to support Android 5 or higher in upcomming CPU's
<apritzel>
to some degree this is Google to blame, really
<hp197>
So sooner or later they will need to have (what is now) mainline support
<apritzel>
because Android != mainline
<hp197>
hmm, I see.. Thought Android 5 was 4.x kernel...
<hp197>
:(
<hp197>
5.x Lollipop |21, 22 |3.16.1
<hp197>
6.0 Marshmallow |23 |3.18.10
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<apritzel>
hp197: well, that's the base version, still
<apritzel>
plus tons of patches
<apritzel>
so any device vendor does not gain anything by supporting mainline Linux, if popular Androids are based on ancient kernels plus Android patches
<MoeIcenowy>
but android will keep old kernel's support
<BenG83>
my Nexus 5X is still running on 3.10.73 with Android 6.0
|Jeroen| has quit [Quit: dada]
<MoeIcenowy>
BenG83: So does my Mi4c
<MoeIcenowy>
(Seems that all 808 come with 3.10
<huawei>
BenG83, so des my P8
<MoeIcenowy>
huawei: so huawei ;-)
<hp197>
But 3.10 Allwinner code isn't directly interchangeable to 3.16 kernel (otherwise we would have already seen Alwinner Android devices running Lollipop), So in near future Allwinner should go fixing their stuff agasin
<hp197>
What?!.. Google allows to upgrade major with old kernel?!
<MoeIcenowy>
hp197: you know it finally.
<hp197>
Damn.... They should change policy....
cnxsoft has quit [Remote host closed the connection]
* hp197
is speachless
cnxsoft has joined #linux-sunxi
<KotCzarny>
'speechless'
<hp197>
peachless :p
<KotCzarny>
preachless :P
<huawei>
hp197, if Google's policy doesn't allow upgrade witho old kernel, most of vendor will never upgrade major Android version
\\Mr_C\\ has joined #linux-sunxi
<wens>
hehe
<apritzel>
huawei: and so most vendors will not upgrade their Linux kernel ;-)
<wens>
isn't google pushing vendors to upgrade recently?
<wens>
or was it the FCC?
<MoeIcenowy>
google is now focusing on hardening of 4.1+ kernel
<MoeIcenowy>
but we cannot pray the vendor for updated BSPs
jernej has joined #linux-sunxi
<huawei>
apritzel, quite contradictory
dearfibonacci has quit [Quit: Leaving]
<MoeIcenowy>
we started from the discussion of SCPI
<hp197>
anyway....
<MoeIcenowy>
and ended with complaining with Allwinner
<hp197>
apritzel: Do you have some spare time to fire up a A20?
<hp197>
From what I can remember it cpufreq worked before (4.4 or 4.5), but seems to be broken in recent
<hp197>
and I would like to have confirmation that it is broken, before I put it up on the wiki
<hp197>
Without a deep investigation but my first impression is: I see they changed to cpufreq-dt and the temp handles in the devicetree are in place for cpu0, so it is a bit unclear why it doesnt like it
<huawei>
hp197, yes, cpufreq broke in my cubietruck, fedora 23 with 4.6 kernel
<hp197>
huawei: Thanks
<hp197>
Will also check somewhere this week the older kernels to confirm it worked before
<huawei>
hp197, also /proc/cpuinfo have not show the cpu freq infomation
<hp197>
But im quiet sure it did...
keh has quit [Ping timeout: 264 seconds]
<wens>
how is it broken?
<huawei>
hp197, however, my old kernel have been deleted because /boot approach full....
<hp197>
it is broken as in, there is no cpu freq info, so no userland cpu freq scheduling
<wens>
funny... my cubietruck works fine with 4.7-rc3 (vanilla)
<hp197>
huawei: I got that message as well, while it was there in the device tree
<apritzel>
that message is in since the dawn of time, I think
<wens>
it has absolutely nothing to do with cpufreq
<hp197>
ok, unrelated then :p
<apritzel>
because the ePAPR demands this property, AFAIK
<wens>
it's just a kind of "compute capacity" indicator
<wens>
apritzel: arm64 doesn't have it, does it/
<apritzel>
yeah, at least there isn't such a message, IIRC
<apritzel>
the problem is that nobody knows which frequency to put in there
<KotCzarny>
all of them!
<hp197>
but another indication that cpufreq isnt loaded (for me) is that this is missing
<hp197>
/sys/devices/system/cpu/cpu0/cpufreq
<hp197>
There is no directory cpufreq for cpu0
FergusL has quit [Read error: Connection reset by peer]
<hp197>
huawei: Do you have cpufreq-dt as module or compiled in?
<NiteHawk>
that "missing clock-frequency" has been around for a long time; and it didn't cause harm - there was even a nice patch by mripard that (more or less) took care of that, but it never made it into mainline
cnxsoft has quit [Quit: cnxsoft]
vagrantc has joined #linux-sunxi
<huawei>
hp197, yeah, i just try to load this module but...nothing
<hp197>
ok
<hp197>
wens: Do you have it as module or compiled in?
<hp197>
huawei: That is also what I say, no message at all (no fault and/or detection)
IgorPec has quit [Ping timeout: 276 seconds]
FergusL has joined #linux-sunxi
<hp197>
huawei: What about: cat /boot/config-`uname -r` | grep CONFIG_INPUT_AXP20X_PEK
<hp197>
Is that a module for you as well?
<huawei>
hp197, yeh
<hp197>
Hmm, that might be the culprint after googling...