<mosajjal>
rellla: yes that's the error. I don't know why it's happenning. It's fine on Arch
<mosajjal>
MoeIcenowy: yes Alpine
caog has joined #linux-sunxi
apritzel has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<MoeIcenowy>
Don't try to enable closed-source driver on Alpine
<MoeIcenowy>
Alpine is not binary compatible with common distros
<MoeIcenowy>
Please change your distro
<MoeIcenowy>
or forget the closed driver
<mosajjal>
MoeIcenowy: just to be clear, I'm using fbturbo not libmali. isn't fbturbo open source ?
<MoeIcenowy>
fbturbo is
<MoeIcenowy>
but you shouldn't enable the UMP support
<wens>
mripard: i wonder how we're supposed to do assigned-clocks with sunxi-ng
<wens>
mripard: just do it in the driver?
<mosajjal>
MoeIcenowy: how can I disable it ? And what will I lose if I disable UMP support ?
<MoeIcenowy>
mosajjal: uninstall libump
<MoeIcenowy>
you will lose nothing if you do not use libmali
<mosajjal>
MoeIcenowy: I did use libump, as you can see the error was generated by libump.so
<wens>
mripard: also i added CLK_SET_RATE_PARENT to pll-cpu, and it now hangs after cpufreq is set :(
<MoeIcenowy>
so try to disable it
<mosajjal>
MoeIcenowy: you mean use fbdev instead ?
<MoeIcenowy>
no
<MoeIcenowy>
you can build a fbturbo without ump
<mripard>
wens: yeah, we should probably do it in the driver
<mripard>
wens: why do you need SET_RATE_PARENT in the pll ?
<mripard>
isn't it based on an oscillator?
<mosajjal>
MoeIcenowy: I didn't know that. And what will I lose by disabling ump ? will the performance drop ?
<MoeIcenowy>
no
<MoeIcenowy>
ump is only used to communicate with libmali
<MoeIcenowy>
you know libmali is not available on alpine
<mosajjal>
MoeIcenowy: I see, can I have a turorial of make options for fbturbo ? And do you recommand cross-compile or pure compile inside Alpine ?
<wens>
mripard: in the 'cpu' clock, sorry
<mripard>
wens: can you add some tracing ?
<mripard>
the set_rate part has really been tested only on the NM clocks so far
<wens>
mripard: i did, and the factors look right, might be a glitch somewhere else i need to find
premoboss has joined #linux-sunxi
<wens>
but recalc_rate seems right
dearfibonacci has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
imcsk8 is now known as imcsk8|zZz
mosajjal_ has joined #linux-sunxi
mosajjal has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
mosajjal_ has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<xEBIx>
Hello, I have some trouble with loading Kernel Moludes in 3.4.104+. This ERROR: "ERROR: 256 KiB atomic DMA coherent pool is too small!" But I did have this in the config "CONFIG_CMA_SIZE_MBYTES=4, CONFIG_CMA_ALIGNMENT=8, CONFIG_CMA_AREAS=7" shouldnt that set CMA to 4M′?
<xEBIx>
Maybe CMA != DMA?
<vpeter>
xEBIx: Maybe you need to increase coherent_pool in boot params? Like coherent_pool=2M.
matthias_bgg has joined #linux-sunxi
<xEBIx>
vpeter: Yes I did that in config already, but I am unshure what is needed elsewhere to make that option work. Is CMA related to DMA or do I not need that for that option to work?
<xEBIx>
In the defconfig CMA is completely off...
ricardocrudo has joined #linux-sunxi
OverCR has joined #linux-sunxi
popolon has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
apritzel has joined #linux-sunxi
<wens>
mripard: forcing cpufreq to performance for now, and sound works nicely
<wens>
the choppiness was likely cpufreq subsystem constantly trying to set the clk rate, and failing
<mripard>
hmmm
<mripard>
did you change the ahb parent to pll6 ?
<wens>
it's already pll6 by default from u-boot
<wens>
but i should add that to the driver just in case
<wens>
also nkm uses the first best factor tuple
<wens>
and it fails at 720 MHz, with k = 1, m = 1, n = 30
<wens>
if i change it to use the last (iterating through possible k values) best value, 720 MHz works, but then fails at 480 MHz
<mripard>
weird
<mripard>
what factors are picked in that case ?
<wens>
let me crash it again :p
<wens>
480 MHz is n=5, k=4, m=1
<mripard>
what happens if you increase the minimum m to 2?
<wens>
let me find some way to hack that in
<wens>
rational_best_approximation doesn't make it easy in this case
<mripard>
well, if you really want something hackish, you can remove it entirely
<mripard>
that's probably going to be easier
<mripard>
and just use for loops instead
<wens>
good idea
cptG has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<MoeIcenowy>
wens: you're failing on which chip?
<wens>
MoeIcenowy: A31
cptG_ has quit [Ping timeout: 240 seconds]
<wens>
mripard: m_min = 2 works, though i get a bunch of warnings on the pll lock polling function
<vagrantc>
anyone used recent mainline kernel with CHIP ? looks like there's some support just based on the device-tree, but not sure how complete it is
<MoeIcenowy>
wens: seems that cpufreq also fails on A33
<mripard>
wens: interesting
<mripard>
the lock wouldn't work ?
<mripard>
that's odd
<mripard>
the timeout is set waay to high already
<wens>
it's also possible that cpufreq is changing the rate really quick? though i thought clk core has a lock on this
aballier has quit [Ping timeout: 250 seconds]
<mripard>
it might
<mripard>
I don't know
<wens>
moving the pll lock wait inside the spinlock
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
<wens>
still getting warnings
Da_Coynul has joined #linux-sunxi
<wens>
mripard: the warning is just a bug in the wait function
<mripard>
which wait function?
<wens>
ccu_helper_wait_for_lock
<mripard>
it's not normal then
<wens>
the condition in readl_relaxed_poll_timeout should be the break condition, not the continue condition
montjoie has quit [Ping timeout: 276 seconds]
enrico_ has joined #linux-sunxi
montjoie has joined #linux-sunxi
<wens>
mripard: i'll send a fix later tonight
aalm has joined #linux-sunxi
lemonzest has joined #linux-sunxi
aballier has joined #linux-sunxi
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 260 seconds]
mpmc has quit [Ping timeout: 240 seconds]
merbanan has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
apritzel: as the user maunal says
<MoeIcenowy>
SDXC_REG_DS_DL_REG is only available on sdc2 of sun50i
<MoeIcenowy>
not sdc0/1
<apritzel>
MoeIcenowy: And, thanks for digging this out
<apritzel>
and we would need a MAKE_THIS_8X_FASTER bit anyway ;-)
<MoeIcenowy>
no wonder allwinner makes dt compatible "sun50i-sdmmc0", "sun50i-sdmmc1", "sun50i-sdmmc2"
<MoeIcenowy>
so no wonder it will timeout
<MoeIcenowy>
so what should be the dt binding?
<MoeIcenowy>
sun50i-a64-mmc0, sun50i-a64-mmc2?
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
enrico_ has quit [Quit: Bye]
enrico_ has joined #linux-sunxi
<mripard>
vagrantc: quite complete, but it's missing the NAND support
<vagrantc>
mripard: right. nand.
* vagrantc
was surprised it didn't have microSD
<vagrantc>
mripard: u-boot has similar issue?
<apritzel>
MoeIcenowy: no, just a property
Amit_T has quit [Ping timeout: 240 seconds]
<apritzel>
so we would set this (boolean) property in the MMC2 node only
popolon has quit [Ping timeout: 246 seconds]
<mripard>
vagrantc: indeed
<MoeIcenowy>
I temporarily commented the code out
<MoeIcenowy>
as we currently have no device with easy-hacking sdc2
<MoeIcenowy>
(device with sdc2 will boot from it
merbanan has joined #linux-sunxi
<apritzel>
MoeIcenowy: I have a a Remix Mini at home, and at least MMC2 worked there in U-Boot
<apritzel>
but this whole thing is more locked down, so I haven't managed to boot a 64-bit kernel there
<apritzel>
MoeIcenowy: but yes, leave it out for now, we can add it later
<MoeIcenowy>
should we leave a "/* TODO */" ?
<apritzel>
it's just a performance optimization anyway, right? So it would work without it, just slower?
<apritzel>
TODO: yes
<apritzel>
mention that it cannot be tested at the moment
mpmc has joined #linux-sunxi
<MoeIcenowy>
yes
<MoeIcenowy>
Remix Mini have some kind of lock?
IgorPec has joined #linux-sunxi
vagrantc has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 258 seconds]
<apritzel>
I could boot via FEL, but it drops me into non-secure SVC only, which is rather odd
<apritzel>
non-secure prevents any RMR switch to get into 64-bit mode
<apritzel>
but somehow the firmware on that eMMC manages to do this anyway
<MoeIcenowy>
FEL is under non-secure SVC?
<apritzel>
on the Pine64 (with an A64) FEL ends up in secure SVC
<apritzel>
which allows to do everything, including the RMR switch
<MoeIcenowy>
but on Remix Mini it ends up in non-secure SVC?
<apritzel>
yes
<MoeIcenowy>
How can that be?!
<apritzel>
but this one has reportedly a H64 CPU
<MoeIcenowy>
H64...
<apritzel>
so either it's something baked in the SoC
<apritzel>
or it's some undocumented configuration pin or the like
<apritzel>
and also not sure if it's just FEL that gets entered in non-secure
<apritzel>
(so that eMMC gets started in secure, for instance)
<apritzel>
I could start my self compiled 32-bit U-Boot with eMMC(2) support, though and access the eMMC (dumping stuff onto an SD card)
IgorPec has quit [Ping timeout: 264 seconds]
<apritzel>
reportedly the H64 has (even) worse thermal characteristics, so a heatsink is more or less required
IgorPec has joined #linux-sunxi
<apritzel>
our understanding is that the A64s are the good chips, which can go without a heatsink (and thus work in tablets)
<apritzel>
for the H64 you need a heat sink, which is fine for TV boxes, for instance
<MoeIcenowy>
It seems that A series are better than H
<MoeIcenowy>
A33 is also better than H3
<apritzel>
MoeIcenowy: don't try to make sense out of marketing names ;-)
<MoeIcenowy>
my new mmc try still ends up at 3.2MB/s...
<MoeIcenowy>
mmc is a mystery
vagrantc has quit [Quit: leaving]
mosajjal has joined #linux-sunxi
Mr__Anderson has quit [Quit: Leaving.]
<MoeIcenowy>
apritzel: Here's a fact: I can achieve 13MB/s under U-Boot
<MoeIcenowy>
14260224 bytes read in 953 ms (14.3 MiB/s)
OverCR1 has joined #linux-sunxi
OverCR has quit [Ping timeout: 276 seconds]
OverCR1 has quit [Quit: Leaving.]
<wens>
need to dump brom?
<plaes>
A64 brom?
<MoeIcenowy>
apritzel: interesting... mmc0 is also different with mmc1
<MoeIcenowy>
smc1 do not support bit 30:28 of REG_FTRGL to be 16...
mosajjal_ has joined #linux-sunxi
mosajjal has quit [Ping timeout: 260 seconds]
popolon has joined #linux-sunxi
<apritzel>
wens: probably, and compare that with the A64 one
IgorPec has quit [Ping timeout: 240 seconds]
<wens>
apritzel: fyi there's a thread on u-boot ML: "How to support ATF on u-boot
<apritzel>
wens: ah, thanks for that
<MoeIcenowy>
I'm felling that I am in a gamble and Allwinner is the banker
_stephan has quit [Quit: Ex-Chat]
dearfibonacci_ has joined #linux-sunxi
DullTube has joined #linux-sunxi
dearfibonacci has quit [Ping timeout: 258 seconds]
pietrushnic`away has quit [Quit: Coyote finally caught me]
caog has left #linux-sunxi ["Ex-Chat"]
kvsari has quit [Ping timeout: 250 seconds]
diego_r has quit [Quit: Konversation terminated!]
Amit_T has joined #linux-sunxi
diego_r has joined #linux-sunxi
pietrushnic`away has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
jelly is now known as ^jelly^
^jelly^ is now known as jelly
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
fire219 has joined #linux-sunxi
mosajjal has joined #linux-sunxi
mosajjal_ has quit [Ping timeout: 264 seconds]
alexxy has quit [Remote host closed the connection]
alexxy has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
OverCR has joined #linux-sunxi
yann has quit [Ping timeout: 264 seconds]
cnxsoft has quit [Quit: cnxsoft]
dearfibonacci_ has quit [Quit: Leaving]
yann has joined #linux-sunxi
mkyr has quit [Quit: Connection closed for inactivity]
<jelle>
didn't know there is also an nanopi o_o, sadly it's 8 dollar for some reason
apritzel has quit [Ping timeout: 244 seconds]
tkaiser has joined #linux-sunxi
<tkaiser>
jelle: _One_ NanoPi?
<jelle>
tkaiser: it's the one from friendlyarm, nanopi neo
<jelle>
$8 dolar + 5 dollar shipping meh
<tkaiser>
jelle: They have a couple boards called NanoPi (M1 and NEO being H3 based)
<jelle>
*yuck*
<tkaiser>
jelle: And for $8 you get only 256 MB RAM (single bank also)
<jelle>
yup
<jelle>
but that's enough if you just need internet + sensors
<jmcneill>
tkaiser: orangepi should be here tomorrow, $20.60 customs fee
<jelle>
:S
<tkaiser>
jelle: True. And since in their fex file they use 432MHz DRAM clock (while all other parameters remained the same) I just checked it. Downclocking DRAM from 624 MHz (Armbian default for all H3 boards now) to 408 MHz means: 200mW less consumption :)
<jelle>
woah
<tkaiser>
jmnceill: Huh, that's a lot! :(
<jmcneill>
afaict DHL in Canada is running a racket
<tkaiser>
jelle: I patched the sun8i legacy kernel to be able to downclock DRAM to 136 MHz. Then testing again. Yesterday I was able to run Orange Pi Lite with just 160mA idle :)
<jelle>
nice
lemonzest has quit [Read error: Connection timed out]
<jelle>
I haven't used my orangepi's yet
<jelle>
for a project
lemonzest has joined #linux-sunxi
<wens>
mripard: might have to wait till tomorrow for that patch, doing a bit more testing
imcsk8|zZz is now known as imcsk8
IgorPec2 has quit [Ping timeout: 244 seconds]
afaerber has quit [Quit: Ex-Chat]
somedude23 has joined #linux-sunxi
afaerber has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
apritzel has joined #linux-sunxi
<MoeIcenowy>
apritzel: I think there may be some issues about DMA
<MoeIcenowy>
IDMA parts should be checked
<MoeIcenowy>
they are mentioned in user manual along with delay calib
Netlynx has joined #linux-sunxi
<apritzel>
MoeIcenowy: what do you mean? Do you see a difference to other SoCs?
jernej has joined #linux-sunxi
zuikis has joined #linux-sunxi
<MoeIcenowy>
apritzel: yes, at least for REG_FTRGL
<apritzel>
MoeIcenowy: where's this FTRGL register, can't find it
premoboss has quit [Ping timeout: 252 seconds]
BenG83 has joined #linux-sunxi
reinforce has joined #linux-sunxi
Andy-D has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
mosajjal has quit [Ping timeout: 246 seconds]
Andy-D has quit [Quit: Alive/Dead]
vagrantc has joined #linux-sunxi
cosm_ has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
tkaiser has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
vagrantc has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-sunxi
maz has quit [Ping timeout: 276 seconds]
enrico_ has quit [Quit: Bye]
mosajjal has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 246 seconds]
mosajjal has quit [Client Quit]
maz has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
tkaiser has quit [Ping timeout: 252 seconds]
tkaiser has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
yann has quit [Ping timeout: 260 seconds]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 272 seconds]
IgorPec2 has quit [Ping timeout: 272 seconds]
IgorPec has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
tkaiser has quit [Ping timeout: 240 seconds]
tkaiser has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<tkaiser>
Nice: By castrating an OPi Lite down to a RPi Zero (running H3 with a single CPU core at 912MHz and DRAM at 264 MHz and disabling nearly everything like HDMI, USB, Ethernet and so on) I'm now at 100mA idle consumption. While still being a bit faster than a first generation RPi (or Zero)
apritzel has joined #linux-sunxi
yann has joined #linux-sunxi
mosterta has joined #linux-sunxi
<KotCzarny>
tkaiser: wow
<KotCzarny>
seriously 100mA?
<KotCzarny>
what about running something on that single core?
<tkaiser>
Running the usual/useless sysbench --cpu stuff on a single core with 912 MHz increases consumption by 300mW (while being faster than RPi Zero)
Netlynx has quit [Quit: Leaving]
aalm has quit [Ping timeout: 276 seconds]
tkaiser has quit [Read error: Connection reset by peer]
<BenG83>
I am trying to build the ATF firmware on my Pine64, is there a repo somewhere that has a gcc-arm-linux-gnueabihf toolchain for aarch64 hosts?
<BenG83>
*u-boot, not ATF
* vagrantc
uses crossbuild-essential-arm64 on debian sid
<vagrantc>
or crossbuild-essential-armhf
<mripard>
gcc-aarch64-linux-gnu on Ubuntu
<vagrantc>
depending on what you're trying to build
<BenG83>
I need to build u-boot and ATF, so I need armhf and aarch64 compilers right?
<apritzel>
BenG83: no, both U-Boot and ATF are 64-bit these days
<BenG83>
ooh
<vagrantc>
BenG83: there are instructions in mainline u-boot board/sunxi/README.pine64
<vagrantc>
but whatever apritzel says might be best current advice :)