<wingrime>
I perhaps someone make normal pacages , or at least make uninstall in make
<wingrime>
ssvb: Looking at timer problem, witch need so much times to do
<wingrime>
I found , that not related is there while
<wingrime>
I mean perf show that "reading" timer regs cost much time
<wingrime>
consider this I think there meaybe 2 variants
<wingrime>
1) cortex core use this timer and "slow down" or "make cache miss" on reading
<wingrime>
2) timer regs mapped incorrectly that make cpu "cache reset" on reading it
rz2k has quit []
rav0__ has quit [Read error: Connection reset by peer]
rav0__ has joined #linux-sunxi
ssvb has quit [Ping timeout: 245 seconds]
ssvb has joined #linux-sunxi
rav0__ is now known as rav0
<ssvb>
wingrime: accessing hardware registers is slow, and the CPU cache can't be used for them (you can try, but will not like the results)
<ssvb>
maybe I should write a reply to hansg's post
<wingrime>
ssvb: but drivers recently access to HW register , but none of this in such top place in perf
<ssvb>
writes are much faster than reads (because the CPU does not have to block until the operation is complete)
<ssvb>
also top place in perf is relative
<ssvb>
we can run ~1 million gettimeofday calls per second on a 1GHz CPU, which means ~1000 cycles per call
<ssvb>
1000 cycles is not too bad (also considering the syscall overhead)
<jelly-home>
ssvb: nice, how much was that gettimeofday() loop unrolled?
<ssvb>
jelly-home: unrolling does not matter much in this case, it can only shave off a couple of cycles which translates to less than 1% overall improvement
<jelly-home>
that much overhead eh
<wingrime>
ssvb: it strange, we have serval dirvers that read and write regs
<wingrime>
None of this in such top place in perf
<wingrime>
I think this timer used by cortex core
ganbold___ has quit [Remote host closed the connection]
<bfree>
wingrime: you can just do a straight rebuild of ubuntu's libdri2 packaging if you want libdri packages on debian. it seemed to work ok when I tried it out
<ssvb>
wingrime, jelly-home: I posted a reply to hansg in the mailing list about aw_clksrc_read
<shineworld>
There is some way to store an img in nand of Cubie ?
ssvb has quit [Ping timeout: 276 seconds]
ssvb has joined #linux-sunxi
<hramrach>
yes
<hramrach>
did you look at the linux-sunxi web?
<hramrach>
ssvb: 32bit counter usefulness .. it depends on resolution
<hramrach>
if it was in microseconds it would give about 4ksec or over 1 hour or sligtly under 1 audio cd
<shineworld>
I've installed LiveSuit but when I run it, after confirm for format paritions" the progress remain always at 0%
<shineworld>
after 20 mins I've closed the app and the nand OS is same of before (never is changed)
<shineworld>
- I've installed dkms to support dynamic kernel module support
<shineworld>
- I've installed with success LiveSuit
<shineworld>
- I've restarted udev with sudo restart udev
<shineworld>
- I've executed LiveSuite with sudo ~/shine/Bin/LiveSuite.sh
<shineworld>
- I've choose one image
<hramrach>
shineworld: I write only from the device - boot from SD card, format flash as normal block device
<hramrach>
and that only for testing that the nad boot works ;-)
<shineworld>
ok... seem LiveSuit was a buggy app
<hramrach>
it works for some people
<shineworld>
sigh...
<oliv3r>
shineworld: also on github we have a 'cleaned up' driver if you wish to re-compile it. the pre-compiled one may be not functioning with your newer kernel
<shineworld>
wow I can do
<shineworld>
git ?
<oliv3r>
github.com/linux-sunxi/allwinner-tools if i'm not mistaken
<oliv3r>
the livesuit that's in there is probably older (but not nessaserly older)
<oliv3r>
i claened up the source for the driver. no guarantees what so ever about its workiness
tinti has joined #linux-sunxi
tinti has quit [Read error: Connection reset by peer]