ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<wens>
MoeIcenowy: function pointers don't have much to do with OO
Andy-D has quit [Ping timeout: 260 seconds]
victhor has quit [Ping timeout: 240 seconds]
reev has joined #linux-sunxi
velly has joined #linux-sunxi
cloud-e has quit [Ping timeout: 260 seconds]
cloud-e has joined #linux-sunxi
cloud-e has quit [Ping timeout: 264 seconds]
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
cloud-e has joined #linux-sunxi
terra854 has joined #linux-sunxi
techping has joined #linux-sunxi
techping has quit [Remote host closed the connection]
lurchi_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 264 seconds]
dr1337 has joined #linux-sunxi
<dr1337>
hi all, does anyone know how to get a hold of V3S development boards?
<dr1337>
Is the lichee zero the only one available?
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
jski_ has joined #linux-sunxi
jski has quit [Ping timeout: 240 seconds]
alsy has joined #linux-sunxi
alsy2 has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Putti has quit [Ping timeout: 240 seconds]
robogoat has quit [Ping timeout: 240 seconds]
robogoat has joined #linux-sunxi
Putti has joined #linux-sunxi
jernej has joined #linux-sunxi
alsy2 has joined #linux-sunxi
alsy has quit [Ping timeout: 268 seconds]
jernej has quit [Ping timeout: 240 seconds]
alsy has joined #linux-sunxi
alsy2 has quit [Ping timeout: 260 seconds]
zumbi has quit [Ping timeout: 240 seconds]
pulser_ has quit [Read error: Connection reset by peer]
bbrezillon has quit [Ping timeout: 258 seconds]
pulser has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
zumbi has joined #linux-sunxi
<KotCzarny>
oh, xunlong listened and renamed orange pi zero plus 2 to orange pi zero plus 2 h3 and orange pi zero plus 2 h5
<KotCzarny>
;)
reinforce has joined #linux-sunxi
alsy has quit [Ping timeout: 246 seconds]
DullTube has joined #linux-sunxi
<plaes>
hrm.. Banana Pi M2Ultra (with R40) costs 50$
<KotCzarny>
yup, a20/r40 are amazingly expensive
<plaes>
I was thinking about getting it to test the ccu patches... but no
<plaes>
wens: is the clock setup of R40 similar to A20?
<MoeIcenowy>
plaes: quite different
<MoeIcenowy>
R40 is in sun6i-style
<KotCzarny>
not 8?
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
Andy-D has joined #linux-sunxi
f0xx has joined #linux-sunxi
<wens>
KotCzarny: the clock layout is either sun4i or sun6i
<MoeIcenowy>
there's no SoC with sun8i name do not use sun6i-style clock, except sun8iw2, which we usually call it sun7i
dr1337 has quit [Ping timeout: 260 seconds]
BenG83 has quit [Quit: Leaving]
<KotCzarny>
ahum
<plaes>
sun7i is a20
florianH has joined #linux-sunxi
massi has joined #linux-sunxi
vickycq has quit [Ping timeout: 258 seconds]
vickycq has joined #linux-sunxi
lemonzest has joined #linux-sunxi
techping has joined #linux-sunxi
Andy-D has quit [Ping timeout: 240 seconds]
Worf has joined #linux-sunxi
LargePrime has quit [Ping timeout: 256 seconds]
LargePrime has joined #linux-sunxi
petard_ has joined #linux-sunxi
Ntemis has joined #linux-sunxi
filt3r has quit [Read error: Connection reset by peer]
<petard_>
MoeIcenowy: Hi. I will bother you again with v3s :/ Please tell me if you've been able to boot lichee with mainline uboot ? I'm able to boot it with sunxi uboot but with mainline it just doesn't work. It says starting kernel and everything goes black. I guess I'm missing the loading addresses. I'm loading script.bin to 0x42000000 and uImage to 0x41000000. Any wisdom ?
BenG83 has joined #linux-sunxi
filt3r has joined #linux-sunxi
<MoeIcenowy>
I remember lichee kernel used different addresses on V3s
<MoeIcenowy>
try to put kernel at 0x42000000 and script.bin at 0x41d00000
<petard_>
Nope, same thing again
<petard_>
Can you give me a pointer what to research ? I don't want to bother you to do my research.
<MoeIcenowy>
the bsp kernel source :-(
<MoeIcenowy>
P.S. have you rebuilt script.bin according to your current console?
<petard_>
yep
<petard_>
the same one boots fine on legacy uboot
<MoeIcenowy>
mripard: the internal osc of A64 is surely 11MHz :-(
<MoeIcenowy>
maybe it's a silicon bug
<MoeIcenowy>
so if the mux is not switch to external osc32k you will get a 22KHz osc32k :-)
<mripard>
MoeIcenowy: iirc, the accuracy is *very* bad on the internal oscillator
<MoeIcenowy>
but both my Pine64 and jernej's Pine64 showed a 11MHz result
<MoeIcenowy>
P.S. creating the rtc-int-osc clock in rtc-sun6i driver is also a bad idea
<MoeIcenowy>
as the iosc is 667KHz on A33, 16MHz on H3/5 and 11MHz ( :-( ) on A64
<MoeIcenowy>
mripard: should I define iosc frequency to 11000000 in A64 DTSI?
<mripard>
which is why I told you to check the RTC before
<MoeIcenowy>
or define as 16000000 as the datasheet said?
<MoeIcenowy>
I think 1/3 error is even too more for a RC oscillator...
<MoeIcenowy>
and the default value of RTC INT OSC divider is also 16, which means Allwinner designed the iosc on A64 to be 16MHz, so the 11MHz should be some bug...
<mripard>
in the A33 at least, the accuracy is 30%
<mripard>
11MHz is within bounds of 16MHz with 30% accuracy
<MoeIcenowy>
11MHz is slightly beyond 30%
<MoeIcenowy>
11 / 16 = 0.6875
<mripard>
your measure might be a bit inacurrate itself
<MoeIcenowy>
yes
<MoeIcenowy>
but it's also possible to make the situation worse
<MoeIcenowy>
I hope there's a method to prevent to switch to iosc even if it's a valid mux
<MoeIcenowy>
so I will follow the datasheet in the patchset I sent now
<MoeIcenowy>
I think no clocks in R_CCU need to have its frequency set in Linux
<MoeIcenowy>
or should we enlarge the accurency value to a higher value, e.g. 50%?
<MoeIcenowy>
mripard: ^
<mripard>
it would be good if you could test all the muxing options
<MoeIcenowy>
I tested all ;-)
<mripard>
just to be sure what those muxes are
<MoeIcenowy>
0 is losc, 1 is hosc and 2 is pll6
<mripard>
on which SoC ? A64?
<MoeIcenowy>
H3/H5/A64 all
<wens>
what do you mean by "no clocks in R_CCU need to have its frequency set in Linux"
<mripard>
so just like A33 then
<MoeIcenowy>
The original ar100-info has code to test mux 0, 1 and 2
clonak_ is now known as clonak
<MoeIcenowy>
I only modified it to test also mux 3
<MoeIcenowy>
wens: I think we have no need to change rates of clocks in R_CCU
<wens>
MoeIcenowy: that doesn't mean something won't depend on reading back the clock rate
<MoeIcenowy>
and mod0 clocks in r_ccu have all only osc32k, osc24M mux (no mux option to AR100 clk)
<mripard>
it depends, it might be useful for the UARTs, IR (maybe?), etc
<mripard>
i2c too
<MoeIcenowy>
yes
<wens>
uarts, i2c, rsb all read the clock rate and set internal dividers
<MoeIcenowy>
reading back do not hurt
<MoeIcenowy>
but we shouldn't have code to put the clock into the so-inaccurate mux 3
<wens>
if you really want to go that route, you can, by just leaving it out of the parent clocks list
<wens>
but you need to be sure that if some other system left the mux at 3, linux has some way to force it out
<mripard>
MoeIcenowy: that depends
<wens>
not sure if the clk core can do that
<mripard>
for something that doesn't really depends on the rate itself
<mripard>
(or that have some tolerancies)
<MoeIcenowy>
I know it depends
<mripard>
using the internal oscillator might make sense if your external one consumes some power for example
<MoeIcenowy>
but I think such an inaccurency can hurt all devices that use it as clock input
<mripard>
the proper way to deal with that would simply be to report its accuracy
<mripard>
and let drivers deal with that
<MoeIcenowy>
ok
<MoeIcenowy>
I think drivers will try to use an oscillator with better accurency, right?
<mripard>
but, I'll state that again, if that internal oscillator is that bad
<mripard>
you want to fix your RTC.
tkaiser has joined #linux-sunxi
<MoeIcenowy>
RTC fixup code is already there in rtc-sun6i.c
<mripard>
yes, and no drivers use it
<mripard>
hmm
<mripard>
s/drivers/DT/
<MoeIcenowy>
nope it's in probe function
<MoeIcenowy>
and forced
<MoeIcenowy>
without any statements
<MoeIcenowy>
just followed after memory remapping
<wens>
right, iirc i requested that
<MoeIcenowy>
it's good ;-) otherwise we will have an osc32k with 22KHz ;-)
<MoeIcenowy>
but now I think having the iosc defined in rtc-sun6i.c is not a good idea -- it should be the second clock input of rtc device node
<MoeIcenowy>
and to be compatible with the dt in 4.11 we can still create the int osc clock in rtc driver if the second clock is not present
<wens>
you can also just add new compatibles for the other chips, such that they register the internal clock at a different frequency
<MoeIcenowy>
but the internal clock is also used by r_ccu
<MoeIcenowy>
and when we ccuizeing the prcm clocks in A23/A33 we will also deprecate the codes that create the int_osc in rtc-sun6i driver
<MoeIcenowy>
as both rtc-sun6i and r-ccu want this 667KHz clock
<wens>
you have a point
<MoeIcenowy>
and I suggest we raise the accurency value of iosc to 40%, as the result on A64 have already reach the value that is little more error than 30%
<tkaiser>
igraltist: And now start htop in another shell, test again and let htop answer the 'what's the bottleneck?' question ;)
<tkaiser>
igraltist: And if you've not switched to performance governor you need a 3rd shell to monitor cpufreq too :)
<tkaiser>
igraltist: If since you mentioned NFS you might also want to look into CPU affinity, where eth0 IRQs are processed and then both taskset and ionice become your favourite tools to improve performance even further. ;)
<tkaiser>
igraltist: And you won't get these 70 Mbits/sec with default DVFS settings since you need to exceed 960 MHz. You're testing your CPU and not network all the time ;)
<igraltist>
cpu speed max is 1008MHz
<tkaiser>
igraltist: Yeah, then this is the maximum you get. Numbers in linux-sunxi wiki are with an overvolted/overclocked A20. Anyway: iperf with SBC --> bottlenecked by CPU
hojnikb has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
<hojnikb>
Anything relevant from xunlong about the 2g-iot board ? They seem to be focusing on countless retardations of h3 boards, but actually producing something with more usefulness (like remote iot projects) ?
<igraltist>
i saw now the peek on 52MB/s on download enough for me :D
<hojnikb>
*iterations
lkcl has joined #linux-sunxi
<hojnikb>
igraltist: 52MB/s is nothing to brag about really :)