Ntemis has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
junnie has joined #linux-sunxi
anarsoul|2 has quit [Ping timeout: 268 seconds]
lkcl has quit [Ping timeout: 268 seconds]
xyntrix has joined #linux-sunxi
<wens>
wait till after -rc1
<icenowy[m]>
smaeul: maybe we can workaroud the timer problem by just dropping the bits that can be unreliable
<smaeul>
icenowy[m]: I think I actually may have found the problem
<icenowy[m]>
?
<smaeul>
for one, the physical counter (CNTPCT) has the same jitter as the virtual counter (CNTVCT), but not as bad
gnufan1 has joined #linux-sunxi
gnufan has quit [Ping timeout: 240 seconds]
<smaeul>
existing errata workaround aren't good enough because our timer is slow enough compared to the CPU that we can read the same bad value twice
<smaeul>
so I wrote my own, but it didn't trap CNTPCT in the kernel, because there was no hook when I wrote it, becase CNTPCT wasn't used
<smaeul>
now CNTPCT *is* used for kernel timekeeping, but until a couple of days ago I didn't know that, and so I just now added the hook for CNTPCT as well
<smaeul>
for two, the jumps that matter are always very close to 2^56 cycles, which is what the arm_arch_timer is defined to wrap around at
chlorine has joined #linux-sunxi
<smaeul>
i.e. a small backwards movement is interpreted as an entire cycle around
<smaeul>
I was able to capture one of the large jumps while running I program I wrote to log jitter: http://ix.io/F65
<smaeul>
the jump backward from 0x00000696bb000000 to something slightly smaller than 0x00000695123fffd5 is what caused the 2^56 cycle leap
<smaeul>
it then corrected itself(!!!), which is the third line above
chlorine has quit [Ping timeout: 240 seconds]
<smaeul>
unlike all of the jitter, which only happens at multiples of 2^10 cycles, and has a very well-defined pattern (0ff -> 000 -> 100 or 0ff -> 1ff -> 100), the numbers here appear to be random
<smaeul>
icenowy[m]: so it's not some high-significant-bit flipping, it's the clock actually *going backwards*
<smaeul>
I need to re-run my tests on a kernel patched to allow userspace to read CNTPCT to see if it affects that timer as well, or just CNTVCT (my hunch is both)
<smaeul>
my logging program only ran for 4 days, and finished before the second jump (from year 2113 to 2208) so I don't have much data to find the pattern here
<smaeul>
there's another timer-going-backward that didn't happen to affect the kernel right after the first one though:
<smaeul>
the relevant leap-causing change is between the two lines: from 0x00000696c4000000 to before 0x00000696c043ed85
<smaeul>
looking back through the logs, here's one where all 4 cpus caught the same jump forward. note that they all **start at different values** but resolve to the same thing:
<smaeul>
I will note that AW sets HAVE_UNSTABLE_SCHED_CLOCK in their BSP kernel, but AFAICT that would only help with the jitter and differences between cores
aalm has joined #linux-sunxi
aalm has quit [Ping timeout: 240 seconds]
<icenowy[m]>
smaeul: I suggest you make a page on linux-sunxi wiki to describe this problem
aalm has joined #linux-sunxi
<icenowy[m]>
call it "A64/Timer Jittering" ?
<smaeul>
icenowy[m]: sure, I'll plan to write up what I know sometime this weekend
jbrown has quit [Ping timeout: 248 seconds]
<icenowy[m]>
jernej: it's only the upper bound of some loop
<icenowy[m]>
to access 0x400{7,8,9,a}xx
dddddd has quit [Read error: Connection reset by peer]
<wens>
naobsd: the super famicom board seems to be different than the famicom?
<Wizzup>
Well, the right entries for `clocks` and `resets`, e.g. CLK_BUS_GPU in the example
<Wizzup>
hrm, I just found CLK_GPU in include/dt-bindings/clock/sun4i-a10-ccu.h ...
<Wizzup>
The example in the arm,mali-utgard.txt file seems to suggest it is for an a20 board, but the entries in there for clocks and resets do not compile for me on recent kernels, hence my question
clemens3 has joined #linux-sunxi
BenG83 has joined #linux-sunxi
<ElBarto>
mripard: Damn, Free can be real assholes
<wens>
Wizzup: BUS enables access to the registers, CLK_GPU is the actual clock that runs the module
<ElBarto>
wens: for the snes mini the only obvious chnges are the removal of uart and mmc test points
<maz>
mripard: that's mad. I'm speechless.
<wens>
ElBarto: but it has marked UART RX/TX pads?
<ElBarto>
wens: I don't remember seeing one and I'm not at home but I can look after fosdem
<Wizzup>
wens: ok. I will try to dig into this further. I understand that CLK_GPU is the one for the gpu core, but I can't figure out what to fill in for the gpu bus clock; for other targets this is more clear, since those have defines for the gpu bus
leviathanch has joined #linux-sunxi
leviathanch_ has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
leviathanch_ has quit [Read error: Connection reset by peer]
leviathanch has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
leviathanch has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
junnie has quit [Ping timeout: 260 seconds]
<mripard>
wens: it does
<hanni76>
mripard: interesting detail - u-boot 2018.03-rc1 is not working with rpi3 ) just not booting.. switching to 2018.01 makes it boot immediately
jogoes has joined #linux-sunxi
<jogoes>
Hi, does anyone know if is possible to use cedar_ve libraries (video encoding/decoding) under Linux 4.10?
<mripard>
hanni76: you should tell the rpi3 maintainer :)
<hanni76>
hi everyone, is there any small display options for Orange Pi PC ? I can't use HDMI and SPI pins are occupied by I2S codec.
hardfalcon has joined #linux-sunxi
fkluknav has quit [Ping timeout: 265 seconds]
clemens3 has quit [Ping timeout: 265 seconds]
<sunxi_fan>
Wizzup: mripard: sorry for the late reply, let me chime in about "A20, Mali, "mainline kenel", DRM/KMS dual head, wayland/weston and libQt5.9.1 and buildroot (the latest git more or less ...)... WHAT a heck of a stack!! :-)
<sunxi_fan>
i started a couple of weeks ago, delving into this "nightmare" because i had to bring an A20 based HW design into a dualhead system, and i currently can say that IT WORKS! :-)
leviathanch has quit [Read error: Connection reset by peer]
<sunxi_fan>
indeed i had to tweak something here and there.. because there are many "pitfalls", but i plan to write somewhere the whole recipe..
<sunxi_fan>
first of all the DTS indeed i had to tweak some info here and there, for the IRQ!
<sunxi_fan>
let me paste somewhere the most relevant snippet of code to make you started eventually..
<sunxi_fan>
i've put "mainline kernel" in quotes because currently i'm working on "sunxi-next" branch of linux-sunxi github account for the basic "dual head capable" DRM/KMS kernel..
<sunxi_fan>
i'd like to know if the recently release 4.15 kernel is full of those patches, because i would be happy to move there, to a "more stable" kernel..
<sunxi_fan>
now, need to get to lunch now, talk you back in half an hour.. sorry!
<Net147>
sunxi_fan: 4.15 does have more of the patches integrated but I did encounter a vsync bug with it
<sunxi_fan>
then i used the mali.ko from free-electrons^Wbootlin github repo
<sunxi_fan>
...and the libMali.so from the "wayland enabled" repo you can find on github from a different user said to be for H3 but indeed working really on A20 too..
<Wizzup>
well, contains the same mali, no? :)
<codekipper>
sunxi_fan: Hi, are you still netbooting your EVB?
<sunxi_fan>
then, as i use buildroot for the overall OS, i tried to bind directly the Qt lib 5.9.3 on DRM/KMS and EGLFS with GBM allocation, but i didn't succeed!! .. i had to resort to use also wayland API and weston as compositor..
chlorine has joined #linux-sunxi
<codekipper>
I've not been able to netboot mine for ages.....resets straight away after starting kernel
<sunxi_fan>
let me tell you in advance i'm NOT really FOND of this graphic stuff, so i've been wading into the sources (or binary blobs..) really like an elephant in a crystal shop! :-) but in the end it worked.. need to streamline stuff.. :-)
<codekipper>
It's been problematic for a while...and now I can only boot it with a sdcard image
<sunxi_fan>
yeah, codekipper (how long.. seeing your stuff on I2S, great you bring it forward!!) still booting on A20 SOM EVB with dhcp/tftp/nfs and so on..
<codekipper>
which is a shame as I could do with the headers
<codekipper>
arrggghh-...been pulling my hair out with this..was a happy bunny and then it started to complain that the kernel image checksum was wrong
<sunxi_fan>
Wizzup: the libMali.so is REALLY picky!!, because the free-electrons site doesn't carry the "wayland" flavour (IIRC for licensing issues...) so we had to resort to a "grey area" and the other repo.
<codekipper>
but it worked with other boards and also when I used a usb2ethernet adapter.
dave0x6d has joined #linux-sunxi
<sunxi_fan>
i struggled a lot for having dual head working on DRM/KMS and "fbdev" emulation but in the end is a "dead end"!! :-)
<sunxi_fan>
nothing about egl currently.. i suppose i have a qt depending on wayland actually.. i used to have something like you say, but it didn't work (maybe i didn't try hard enough.. of course it could be!)
<sunxi_fan>
[02:86:04:42:4e:66] #
<sunxi_fan>
[02:86:04:42:4e:66] # tree /usr/lib/qt/plugins/wayland-graphics-integration-server/
<sunxi_fan>
yes you are right i WOULD NOT need the Mesa step, but currently the Weston on DRM is enabled only if Mesa3D is there..
<Net147>
sunxi_fan: right. it should work with QT_QPA_PLATFORM=eglfs QT_QPA_EGLFS_INTEGRATION=eglfs_kms.
<Net147>
sunxi_fan: otherwise it tries to load eglfs_kms_egldevice or something first and fails
<Net147>
sunxi_fan: but wayland/weston may work better for you if you have more than one application
<sunxi_fan>
i could be, now that i have a "proof of concept" showing the dual head, i could "backtrack" a bit and try as you say..
<sunxi_fan>
i also tried this patch (http://lists.busybox.net/pipermail/buildroot/2017-November/206433.html don't know if Benetti is online here currently.. ) to "fold" into the buildroot mechanism the libMali.so support but of course it's still pointing to the "licensed" libMali.so from free-electrons git repo, then IIRC it doesn't enable the same env var needed by Weston to light on the DRM flavour..
<sunxi_fan>
so i had to move in a different way, because i at least had to show something working (fairly) well...
<sunxi_fan>
Net147: i didn't need to have a complete window manager, and let me tell you that "the Weston" is hitting the A20 SOC with a 10% CPU in a fairly idle (spinning triangle.. in a window only..) screen..
<sunxi_fan>
so i would be more then happy to reduce the stack involved.. i really don't know HOW reliable would be such system in a 24/7 embedded environment, indeed.. that's my main concern!
BenG83 has quit [Ping timeout: 252 seconds]
IlyaM has joined #linux-sunxi
<sunxi_fan>
i've recently read that Ubuntu retracted from release the next 18.04 LTS with Weston as default window manager and that rings a bell on me.. what do you think? anyone with experience/ feeling about the Weston ?
<Net147>
sunxi_fan: I have never used weston on A20. good work getting it running.
<Net147>
sunxi_fan: if you use USB in your application...
chlorine_ has joined #linux-sunxi
clemens3 has joined #linux-sunxi
chlorine has quit [Ping timeout: 264 seconds]
<sunxi_fan>
Net147: interesting.. thanx. never heard bout it; "powermeters" maybe release spikes on USB. it's anyway a pretty poor error report.. which kernel, which settings, who knows!? the one thing i learned on such "fairly complex" HW/SW artifacts, is that we can share the "lessons" about the "methods on how to deal with it.." more then "ready to go" recipes. every installment has its own quirks! :-)
iamfrankenstein has joined #linux-sunxi
<Net147>
sunxi_fan: I have seen it happen sometimes
<sunxi_fan>
codekipper: just read about your issues with A20 SOM EVB, looks like a board "slowly dying" someway i suppose.. what a pity!
<sunxi_fan>
mine is pretty happy still today (and i (ab)used those headers quite a lot..) :-) luckily enough we all have plenty of other fairly cheap boards to play with, but i can understand having such an expensive gear becoming a brick is a little saddening! :-|
jstein has quit [Remote host closed the connection]
<jogoes>
Is it possible to use the cedar_ve libraries (video encoding / decoding) in Linux 3.4, eliminating the camdroid layer?
BenG83 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
junnie has quit [Ping timeout: 256 seconds]
chlorine has joined #linux-sunxi
tom_nov has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 276 seconds]
matthias_bgg has quit [Quit: Leaving]
jbrown has joined #linux-sunxi
ircfan has left #linux-sunxi ["bye"]
junnie has joined #linux-sunxi
BenG83_ has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
BenG83 has quit [Ping timeout: 248 seconds]
chlorine has quit [Ping timeout: 252 seconds]
jogoes has quit [Quit: Page closed]
fkluknav has joined #linux-sunxi
BenG83_ has quit [Remote host closed the connection]