<_mamalala_>
hopefully a newer mainline kernel will have full h3 support ... then i can try to add FIQ handling there, which should result in even better results
<_mamalala_>
i'm not using any kernel timer at all ... i directly use the TMR1 from the H3, which is completely unused
<_mamalala_>
heck, even TMR0 would be unused, only some test-module actually uses it ...
<_mamalala_>
and from what i can see, the high speed timer of the H3 is unused as well
<_mamalala_>
the same is probably true for other allwinner chips running linux as well
IgorPec15 has joined #linux-sunxi
<_mamalala_>
good morning IgorPec15
<_mamalala_>
topi`: usually it's not really possible to drive stepper motors smoothly under linux without extra hardware, i wanted to change that for my own project ... and so far it looks quite promising
IgorPec15 has quit [Ping timeout: 244 seconds]
<topi`>
_mamalala_: maybe it depends on the architecture?
<_mamalala_>
yes and no
<topi`>
was this the main reason why those "windows modems" never really worked with linux? being run by software...
<topi`>
windows modems from early 2000s :)
<_mamalala_>
older arm chips have a VIC, there you can easily use the FIQ for such stuff ... modern arm chips use a GIC, so it's not that easy anymore
<topi`>
yeah a GIC essentially looks like an intel interrupt chip
<_mamalala_>
and then there are hybrids that have arm cores plus one or two extra cores for realtime stuff that run dedicated code
IgorPec has joined #linux-sunxi
<_mamalala_>
otoh, the GIC does have two interrupt groups ... but then, the old 3.4.x kernel doesn't make use of that either
<topi`>
well 3.4.x should be retired by now :)
<_mamalala_>
and diving into the depths of that old code is just too much ... so i went for the brute force approach :P
<topi`>
he's like an overworking pensioner who hasn't realized that the pension money is already coming :D
<topi`>
poor 3.4.x
<_mamalala_>
yea, it should ... but then, current mainline kernels should have full support for the h3, which they don't
<topi`>
some bits might take a while to come... I just need a working CSI camera :D
<_mamalala_>
ha, don't be so sorry for the 3.4 .... just look at all those cheap routers and other gadgets that still ship with 2.6 :P
<topi`>
specifically, the Xunlong camera module support
<_mamalala_>
the 2.6 kernel is like a zombie, it just won't die ... haha
<topi`>
yeah, I know the feeling. My work mate ordered a "brand new IoT gateway" a while ago, and we were utterly surprised to find out it runs kernel 2.6.38 !
<topi`>
which was out, what, 10 years ago??
<_mamalala_>
yea, eons ago
<topi`>
I worked for Nokia then, and we based the Maemo OS on 2.6.18
<topi`>
which became the Nokia N900
<_mamalala_>
initially i had the silly idea to make a diff between the sunxi 3.4.39 kernel and a current one ....
<topi`>
then you found out about the size of that diff? :D
<topi`>
let me guess, a million lines??
<_mamalala_>
well, that didn't work, obviously, so i tried a diff between sunxi 3.4.39 and standard 3.4.39 ....
<_mamalala_>
which made it pretty clear that the sunxi kernel is a frankenkernel all by itself already
<topi`>
yes, patched and patched
<topi`>
and god knows in which order
<_mamalala_>
lots of patches that are not directly related to their stuff, lots of packported patches
<topi`>
well backports are good, aren't they :D
<_mamalala_>
the fact that their own code, and the sunxi-realted patches to the original codebase, are of such poor quality probably doesn't help the integration into mainline either
<topi`>
exactly
<_mamalala_>
... not to mention the virtually non-existant documentation from them
<topi`>
many big companies did learn their stuff the hard way, like TI, Freescale, AMD...
<topi`>
but the chinese still have to learn
<_mamalala_>
"the chinese" is too broaf a brush
<topi`>
initially, year 2006, even TI was doing this frankenstein development on the linux 2.6
<_mamalala_>
there are excellent companies as well ... and there are bad non.chinese companies too
<topi`>
it took them several years and 3 iterations with us (Nokia) to make that right
<_mamalala_>
yea
<topi`>
but they learned, and now everything is rather smooth concerning their chips and mainline linux
<_mamalala_>
it would be a great help if they would at least publish usefull documentation .... heck, i even would be happy with a full manual in chinese ... someone will come along and translate it
<topi`>
(I'm not really well into this knowledge since I don't nowadays work with TI chips, but the Beaglebone is probably pretty good)
<_mamalala_>
but all we have are rather lousy datasheets that basically just list the register, and give little info on the actual use
<topi`>
do you have any "excellent" chinese companies in mind? they all struggle with the kernel process
<_mamalala_>
not really off the top of my had
<topi`>
Amlogic is just as bad as AW, but they did release the S905 data
<_mamalala_>
head
<topi`>
perhaps Rockchip is trying to behave better, since their actual employees push patches to mainline
<_mamalala_>
but i had contact with some in the past years that had no problem in sending me full manuals and stuff
<_mamalala_>
but then, it's also somewhat of a hit-and-miss .... depends who you end up with when you make contact
<topi`>
evidently that plays a big role :)
<topi`>
the chinese I was in contact with from both Allwinner and Merrii did not even seem to understand my questions...
<_mamalala_>
still no worse than western companies and their silly NDA crap for documentation ... i mean, do they want people to use their stuff or not?
<topi`>
true, that
<topi`>
I never understood that overjealousness
<_mamalala_>
yea
<topi`>
just look at ARM/MALI
<topi`>
I had the same experience while we worked with the first Imagination shader core, the first SGX
<_mamalala_>
what irks me most are all the SoC, µC and CPU companies that happily sell their stuff, use Linux as a big marketing thing, but then refuse to open up at least their documentation ... damn freeloaders .P
<topi`>
the fact that I even watched their bloody powerpoint slides, implied that I was under a NDA
<wens>
nah, officially you still have to sign an NDA to work with the Chinese companies
<_mamalala_>
i mean, i don't expect free support for them or such ... but hey, at least give me some usable docs so that i can try and figure stuff out on my own
<wens>
the engineers just hand stuff to you if convenient
<_mamalala_>
ha, it often is quite fun to read the actual NDA's ... more often than not they are not worth the bits they use up in the PDF
<_mamalala_>
like, when was it ... a year or two ago, when i hacke the ESP8266 wlan microcontroller
<_mamalala_>
i got them to have me sign an NDA ....
<topi`>
wens: in the western companies, engineers are afraid of committing a "mistake" if they released stuff without a proper NDA
<_mamalala_>
... which had funny clauses in it which basically translated to "well, if you punlish the info we can't do squat anyways"
<_mamalala_>
publish
<topi`>
"if you publish, we will sell your grandma for slavery"
<_mamalala_>
nope
<_mamalala_>
damn, i can't find the nda on a quick search ... i have it somewhere ...
<_mamalala_>
and in the Confidentially section are some gems as well
<_mamalala_>
the stuff under the exception clause basically gives a free pass if one wants to be nasty
<_mamalala_>
sign the nda, give the info to someone else, have that person publish it anonymously, done
<_mamalala_>
after that you have a free pass to publish it yourself, because, uh, someone else already did :P
fire2191 has quit [Read error: Connection reset by peer]
<mripard>
_mamalala_: "Now, not only is that a long way to go, but in many of those functions a lot of other functions are called, many of which are by themselves interruptible/preemptible." that's not really true
<mripard>
interrupts handler are run with interrupts masked
<mripard>
and that's very likely to be the cause of your jitter
<mripard>
under stress, you get more interrupts, they're masked more often, which increases the latency
<_mamalala_>
mripard: up to a point only, otherwise there would be no need to keep track of the depth, i think
<mripard>
I think the depth tracking is only for tracing
<_mamalala_>
mainly preempting, that is
<mripard>
but the first thing handle_fasteoi_irq does is raw_spin_lock
<_mamalala_>
i mean, if the call tree would be non-interruptible, non-preemptible, one would just expect a somewhat fixed latency, but that isn't the case .... ah, yes, and spinlocks
foxx_ has joined #linux-sunxi
<mripard>
it is
<mripard>
if you just have a single interrupt source
<_mamalala_>
hehe, yea
<mripard>
which is not the case
<mripard>
if you have two interrupts (or more) coming at around the same time
<mripard>
the second handler will be delayed until the first one is done
<mripard>
which means additional latency
<mripard>
which means jitter
<mripard>
and of course, it only gets worse when you add more interrupts into the mix
<mripard>
and under stress, you can easily have a significant number of interrupts coming in your system pretty much all the time
<_mamalala_>
indeed
<mripard>
storage, network, UART if you have a console, timers, etc.
<_mamalala_>
yea, as said, my approach is quite brute-force, but works fine for the intended use
foudubassan has joined #linux-sunxi
<mripard>
so you just increase the average latency, but in an entirely non-deterministic way
<mripard>
this is what xenomai and preempt-rt are about
<_mamalala_>
i just hope that once there is good support for the H3 in the mainline kernel, i can add FIQ handling there
<mripard>
yeah, I did it in the past
<mripard>
precisely to drive some steppers
<mripard>
it was working quite well
<mripard>
but it wasn't with a GIC
<_mamalala_>
hehe, VIC then, i guess?
<_mamalala_>
i guess the incomplete/non-existing support for groups with the GIC is the reason the 3.4 kernel fails to boot in non-secure mode
<_mamalala_>
from what i gathered, it seems that all IRQ's are in group 0, which normally would be secure mode
<_mamalala_>
(and FIQ)
<_mamalala_>
but in 3.4 there seems to be no seperation, so all is considered "secure", i think
<_mamalala_>
i can shift the TMR1 to group 1, for example ... and it still gets registered and the calls counted up ... but the handler itself never gets called
<_mamalala_>
alas, peeking at the group id of other interrupts shows them all as group 0
<wens>
topi`: i guess that's because copyright litigation is more developed? :p
<_mamalala_>
ah well ... as said, i hope that a new mainline kernel is ready sometime soon-ish ;)
<_mamalala_>
for now the dirty hack has to do
mosterta has joined #linux-sunxi
lennyraposo1 has quit [Quit: Leaving.]
dearfibonacci has joined #linux-sunxi
lennyraposo has joined #linux-sunxi
mosterta has quit [Ping timeout: 260 seconds]
<wens>
_mamalala_: mainline u-boot has FIQs running in monitor mode
iamfrankenstein1 has joined #linux-sunxi
<mripard>
_mamalala_: no, I did it on two systems, the imx28 that has its custom interrupt controller
<mripard>
and the tegra2 with a gic and a custom one
<mripard>
and I was using the custom one for the FIQ
IgorPec has quit [Ping timeout: 264 seconds]
iamfrankenstein has quit [Ping timeout: 276 seconds]
iamfrankenstein1 is now known as iamfrankenstein
MiLeon has joined #linux-sunxi
pg12 has quit [Ping timeout: 250 seconds]
lennyraposo has quit [Quit: Leaving.]
pg12 has joined #linux-sunxi
pg12 has quit [Ping timeout: 265 seconds]
pg12 has joined #linux-sunxi
popolon has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
lemonzest has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
premoboss has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
enrico_ has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
dearfibonacci has quit [Ping timeout: 258 seconds]
<MY123>
should I try the downstream nVidia and Qualcomm kernels or the upstream kernel(note that I have no UART/JTAG/...)
<MY123>
JTAG is disabled in the OTP fuses
MXfive has quit [Read error: Connection reset by peer]
<MY123>
It's stuck somewhere, and I have no way to debug
<libv>
this does not sound like a sunxi thing
<MY123>
libv, yep, Allwinner very weirdly states that Windows devices using their SoCs exist, but I saw exactly zero mentions in Microsoft driver packages
<MY123>
like, they say that the A20 can run RT, but it has a Mali-400 GPU which has no drivers that I know of(unlike Mali-T)
<MY123>
Rockchip is officially mentionned in the docs that I have
MXfive has joined #linux-sunxi
<MY123>
(Freescale i.MX6 also)
foxx_ has joined #linux-sunxi
perr has joined #linux-sunxi
Putti has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]
jstein has quit [Remote host closed the connection]
perr has quit [Quit: Leaving]
vishnup has joined #linux-sunxi
MXfive has joined #linux-sunxi
vishnup has quit [Ping timeout: 276 seconds]
paulk-nyan-big has joined #linux-sunxi
vishnup has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
MXfive has joined #linux-sunxi
therealfibonacci has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]
MXfive has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]