LoCoZeNoz_ZUE has quit [Remote host closed the connection]
<PiyushVerma>
ssvb: I will check with overclocking today
<PiyushVerma>
Turl: Video playback exxample already using some accelerated rendering method
<PiyushVerma>
current main problem is we are enable to buffer decoded frame.
<PiyushVerma>
I think if that could be posisble performance could be batter.
<PiyushVerma>
By the way which version of linux kernel is suggested to use now
<PiyushVerma>
ssvb tested overclocked with 360Mhz result same
wingrime has joined #linux-sunxi
<wingrime>
who can explain how get vlc working
<wingrime>
I just build it and i\vlc cant play an video
<wingrime>
like not supported h264
<PiyushVerma>
how did u run that and what's issue ?
<wingrime>
look like ldconfig was needed
hozer has joined #linux-sunxi
shineworld has joined #linux-sunxi
ganbold has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
<wingrime>
oliv3r: are you here ?
theOzzieRat has joined #linux-sunxi
n01 has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: reboot]
wingrime_ has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
\\Mr_C\\ has joined #linux-sunxi
hglm has joined #linux-sunxi
hsildaerD has joined #linux-sunxi
Dreadlish has quit [Ping timeout: 246 seconds]
foubarre has joined #linux-sunxi
dragonn has joined #linux-sunxi
mab_ has joined #linux-sunxi
<mnemoc>
oliv3r: pong
\\Mr_C\\ has quit []
<mnemoc>
will have to reboot the sunxi server now. need to fix a f* up btrfs
ozonys has quit [Quit: Page closed]
\\Mr_C\\ has joined #linux-sunxi
<oliv3r>
wingrime: yeap
<oliv3r>
mnemoc: hi
<oliv3r>
Turl: what makes you say that N looks more like a P? We can rename it to P if you want, but the source is quite specific: __u32 ClkDiv:4; //bit0, clock divide ratio, divided by (m+1),
focus has quit [Read error: Connection reset by peer]
focus has joined #linux-sunxi
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
foubarre has quit [Remote host closed the connection]
user_2 has joined #linux-sunxi
foubarre has joined #linux-sunxi
<foubarre>
Hello. I am using a wheezy debian on an allwinner A10 system. I try to compile iscsitarget-dkms, however it complains about a missing timex.h (arch/arm/include/asm/timex.h iirc). Is this the place where i can ask what is that file and how to obtain it?
<oliv3r>
it's part of the kernel header
<oliv3r>
so you either haven't installed all your build prerequisites (e.g. linux-headers) or you are using old ones
<foubarre>
oliv3r: i got the headers from git, and they were sunxi3.4 (.49iirc)
<oliv3r>
you got some random headers and hope it would work?
<foubarre>
oliv3r: random?
<mnemoc>
having hope is a good thing
<oliv3r>
mnemoc: lol
<oliv3r>
foubarre: well you are trying to mix and match random bits and parts and hope it works?
<mnemoc>
oliv3r: btw, can you mail me your post address?
<oliv3r>
hope is a good thing :)
<oliv3r>
e-mail? sure; whats your e-mail
<oliv3r>
oh i know
<oliv3r>
do'h
<oliv3r>
will do
<mnemoc>
oliv3r: physical
<mnemoc>
thanks
<oliv3r>
foubarre: git clone the entire kernel; build the entire kernel and enable iscsi-target
<foubarre>
oliv3r: where else can i obtain the kernel sources for the A10?
<oliv3r>
foubarre: you are using the iscsitarget-dkms, which uses 'who knows what kernel sources' and depends on who knows what headers
<mnemoc>
foubarre: you need to patch the kernel you are running
<mnemoc>
s/patch/match/
<oliv3r>
you are not using an apt-get install kernel-image; so you can't use linux-headers equally not, so I wouldn't use any dkms
<oliv3r>
unless 3.4 doesn't have iscsi-target support; at which point you'll be in trouble anyway :)
<oliv3r>
you'd have to port/backport it from mainline to 3.4
<oliv3r>
which is a little work, but quite possible
<oliv3r>
mnemoc: check your e-mail
<oliv3r>
mnemoc: i think i scared him :(
<foubarre>
i built the kernel, installed it and build the headers with it. Both were in sync. However, i understand you mean that i'm a bit doomed. Do you know valuable links to resources that explain tips to backport, so that i don't learn myself from the goundup?
<mnemoc>
oliv3r: :)
<oliv3r>
foubarre: if you've built your kernel, do make menuconfig or make linux-config if you use the BSP
<oliv3r>
find the iscsi target option, built it as module/kernel; done
<foubarre>
oliv3r: been there.. i found no iscsi target.
<mnemoc>
moving the OS from uSD to NAND is distro independent
<user_2>
if i do everything on uSD, then can i move the "image" to flash?
<oliv3r>
you are building a rootfs
<oliv3r>
you end up with a .img
<oliv3r>
i don't think it matters if you dd it to /dev/sd0 or to /dev/nandd
<mnemoc>
rellla has a quite decent debian-unstable-armhf rootfs tarball on dl.
<mnemoc>
bsp-friendly ;-)
<mnemoc>
going to stop the wiki again :( hope it's the last time
<oliv3r>
ouch
<oliv3r>
ok, restart more
<mnemoc>
corrupted btrfs
<mnemoc>
that's why writting is so slow
<oliv3r>
foubarre: if you really need iscsi-target (and it really isn't under some hidden combination of options in 3.4) I suppose you'll have to cherry pick all commits from mainline 3.4 -> where it does work
luoyi has joined #linux-sunxi
<oliv3r>
foubarre: if iscsi-target is an external patch to the kernel (and hence the dkms) you'll have to take the patches for the 3.4 kernel;a nd apply them to the kernel before doing linux-cofnig :)
<foubarre>
oliv3r: so, i should first triple check that i can not be enabled using single/various options when compiling. Where would you start to look into if you were to find no "iscsi target" red blinking option in the config?
<oliv3r>
use / to search, then type 'iscsi' or 'target' and see what comes up :)
<oliv3r>
i don't know if iscsi-target is still a seperate patch
<mab_>
oliv3r: I'm still trying to get backlight PWM working. There is HAVE_PWM in the kernel config but it is hidden until you use another architecture. Or should I rather use the fex file?
<oliv3r>
mab_: i think 3.4 and 3.0 have backlight implemented directly in the display core
<oliv3r>
3.11 will use the generic pwm/backlight framework
<mab_>
oliv3r: so how can I access it in 3.4?
<PiyushVerma>
is there any documentation how to run xface with x11 mali support
<PiyushVerma>
or a prebuilt image with that
<foubarre>
oliv3r: ok, will do. thank you.
<luoyi>
after I connect the usb mouse through usb hub. dmesg will show many msg like " init new usb devices: 001/002/003 " and so on
\\Mr_C\\ has quit []
<luoyi>
does this mean that the kernel's usb support is not perfect ?
<mnemoc>
nothing is perfect
<mripard>
oh, about USB, it seems like the USB IP is actually the inventra from mentor graphics
<mripard>
which already have some support in the kernel
<mnemoc>
mripard: do you have an A10S with uart?
<mripard>
no I don't
<mnemoc>
:(
<mripard>
I'm supposed to receive one from Olimex
<mripard>
but you too iirc
<mnemoc>
yes.
<mnemoc>
but i'm eager to know if the soc-detect code detects A10S properly
<mnemoc>
it should. but want a confirmation
<mnemoc>
before rearanging the code and submit it for review and comments
<oliv3r>
mripard: i heard T.... say something about that yesterday, that means we can stop all our USB efforts and use that instead? :)
<mripard>
T?
<mripard>
yeah, that would be the plan I guess.
<mripard>
at least do some testing
<oliv3r>
tech? turl? i forgot, i think it was Turl
<mnemoc>
wasn't it arnd?
<oliv3r>
i'm sure there's more IP from other companies in there :)
<oliv3r>
no Turl commented that arnd commented
<oliv3r>
:)
<mripard>
Arnd pointed us to it yesterday, on another channel
<oliv3r>
mripard: i'll clean up my sid patch btw, and resubmit it with the fixes in it, since there's been no more comments. i'll use a seperate commit for the 'randomizer' bit
<mab_>
oliv3r: ok, thanks for looking it up. I grepped for "backlight" "brightness" etc. in /sys, nothing. How do I get there, GPIO's?
<oliv3r>
and that's why i couldn't find it on gmane :p
<oliv3r>
mab_: you can't
<oliv3r>
mab_: i do not know how android exposes backlight functionality, but the 'code' is in dsp, probably under pwm
<oliv3r>
mab_: though I think hansg's fedora image uses brightness for the backlight aswell; so there must be some obvious way :)
<oliv3r>
i simply don't know :)
<hramrach_>
ssvb: I enabled the mt options in mplayer and tried the really choppy video on a 4-core cpu and it does way better than Cedar
rellla has joined #linux-sunxi
<mab_>
ok, will look into the fedora image. When reading in bed my GF complains about too much light :-)
<mripard>
oliv3r: merge the entropy into the driver patche directly
<oliv3r>
mripard: so 2 patches, 1 for dt; 1 for everything
<mripard>
yep
<hramrach_>
some very close objects are still a bit choppy in one scene but overall it's quite smooth so Cedar is to blame for the choppiness on A10 :s
<oliv3r>
mripard: done
unioah has left #linux-sunxi [#linux-sunxi]
<ssvb>
hramrach_: it would be also interesting to test it in native android
<ssvb>
hramrach_: any other interesting details about this video?
<hramrach_>
yes, could try to get android on a card or something
<hramrach_>
there is a short clipping in the samples because it causes fpe in vlc
<hramrach_>
so you can mediainfo it to pieces
<ssvb>
hmm, is it a single "bad" file? or many similar files exhibit the same problem?
<hramrach_>
they are expensive to decode
<hramrach_>
720p but fail on 2GHz core2 single-threaded pretty much the same as they do on A10
<ssvb>
finding transcoding parameters for Sintel or some other free video sample to reproduce the same problem would be great
<hramrach_>
thre are cpu spikes during decoding. you need like ~120-150% of the 2GHz core to decode I guess
<mripard>
mnemoc: cool :)
<mripard>
and so this A12 is really different from the A10s?
<mnemoc>
no idea :(
<ssvb>
PiyushVerma: what is xface? does it support OpenGL ES?
<hramrach_>
ssvb: well, the clipping is very short so it should be free enough for testing purposes
<mnemoc>
mripard: hopefully these "tricks" will help to unify drivers and unify u-boot stuff too... maybe even multi-sunxi 3.4 kernels
<hramrach_>
iirc it decodes really poorly on Cedar
<mnemoc>
mripard: but on mainline you need to rely in the .dtb anway...
<mripard>
mnemoc: yep, I think it's great for 3.4 to have a shorter path to mainline eventually
<oliv3r>
we haven't seen an A12 in the real world, but code does say it exist(ed)
<mripard>
but yeah, like you said, this information is already stored in the dt, some I'm not really sure it's needed there
<mnemoc>
mripard: are you allowed to "verify" that you got the dtb for the right soc?
<mripard>
but it's great to know that it works in case we actually need it
<oliv3r>
well what if you have several boards, all with 2 random SoC's
<mnemoc>
to printk a warning or something
<oliv3r>
that are 99.9% identical, but differ on small bits
<oliv3r>
and the manufacture has no way to differentiate between two said boards
<oliv3r>
think cubieboard a10, cubieboard a20
<mripard>
mnemoc: I'm not sure it's useful to check that actually :S
<oliv3r>
sure, they would need different dtb's
<mripard>
because, if you detect a SoC change, what are you going to do ?
<oliv3r>
but what if the manucature wants to use the same one for his entire stock, because the drivers are all identical
<mnemoc>
mripard: printk something so the user understand what's wrong
<mripard>
print something ? on which UART ?
<mnemoc>
:)
<oliv3r>
i just think it's a little dangerous, to soley rely ont he dtb
<oliv3r>
especially, what if its a closed box, and you can't read the label off of the chip
<mnemoc>
oliv3r: it doesn't really matter if dtb is a good idea or not, it's what it must be used and that all.
<mripard>
and what if for some reason, the sid isn't filled right ?
<oliv3r>
while a10 vs a20 is easy to differentiate
<oliv3r>
but what about a10 revA; vs a10 revB
<oliv3r>
where there where some fixes in the soc itself
<oliv3r>
mripard: soc_detect doesn't depend on sid :p
<oliv3r>
sid isn't filled right on hno's mele
<hramrach_>
so some machines can have it wrong or it can be erased
<hramrach_>
either way you can't rely on it
<oliv3r>
some devices have 0
<mripard>
oliv3r: oh, I thought so, my bad
<oliv3r>
soc detect works on lots of other things
<mnemoc>
mripard: SID is only used to detect the revision of sun5i socs. not to detect the sunNi or the soc
<mripard>
ok
<oliv3r>
well its only usefull to 'help' identify, but can be 0
<oliv3r>
mripard: btw, it may be, that you can only program SID fi you apply 12V programming voltage to 1 pin
<oliv3r>
so it might not be possible for users
<mripard>
oliv3r: oh, good to know
<oliv3r>
there's an input pin, efuse_vddq; that's tied to gnd per default
<oliv3r>
so our guess right now is, it needs a programming voltage (not uncommon) to enable programming
<oliv3r>
or atleast needs to be pulled high, but 'vdd' kinda makes you think programming
<oliv3r>
hno tried to 'write' his 0 sid, but didn't work
<hramrach_>
not if the pin is not connected to anywhere
<hramrach_>
pulling a disconnected pin of BGA chip is kind of hard
<oliv3r>
exactly
<oliv3r>
and if it's connected to GND per default (aw recommendation)
<hramrach_>
if it's connected to ground maybe you could break it and use jumper wire but still
<oliv3r>
then try to 'change' that
<oliv3r>
yeah, but if the pin is under the soc, how in the world would you do that :)
<oliv3r>
the gnd plane probably comes up right next to the pin
<hramrach_>
right, depends on the routing of the board
<mnemoc>
oliv3r: can you see if writing on the wiki feels faster?
<hramrach_>
ssvb: also I doubt you can just apply the encode parameters. the bulk of the video is ok. just some with much changes are choppy
<hramrach_>
and you would need only slightly compressed/uncompressed video to apply to
<hramrach_>
since once the data is clipped you cannot conjure it back
<oliv3r>
mnemoc: saving, i can, need to write a little bit about SID anyway
<mnemoc>
:)
rz2k has joined #linux-sunxi
<oliv3r>
mnemoc: can you install the plugin 'pdf-book'? :)
<ssvb>
hramrach_: first we need to confirm if it is likely a limitation of cedar hardware, or just linux players (vlc & xbmc) are doing something wrong
<hramrach_>
yes, need to get some android for testing as well
<oliv3r>
hno: we need a 'sacrificial' A13, since that has a gul-wing package we could use to expose efuse-vddq from :p
<hramrach_>
it it possible to install on a sd card?
<oliv3r>
mnemoc: not really faster; maybe 6 second instead of the 9 from before
<oliv3r>
still, better I suppose
<hramrach_>
there is CWM on a SD card page so maybe it could be used for others
<mnemoc>
uhm
<bfree>
mripard: I think now might be the time to re-submit wemac support to mainline? only 2-3 weeks to get it considered for 3.11 afaik and it's likely to end up needing a patch iteration or two ... unless I'm missing something? thanks for all the work!
<oliv3r>
bfree: emac*
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
<oliv3r>
mripard: IF emac support is based/looks a lot like u-boot's version, it needs a patch on the init sequence; the MDC is setup to late in u-boot (hno fixed it) which puts out 48 MHz on the PHY, POSSIBLY (unconfirmed, but mine could have been from that) breaking the PHY
<oliv3r>
i tried to find it in your tree, but somehow didn't find it
<oliv3r>
mnemoc: some people like to have some pages for offline usage
<oliv3r>
turl for example, shuns the wiki, even though it is more complete, because sometime he needs to access it offline/locally; and the pdf is faster herin
<oliv3r>
so being able to download a page(s) in pdf is quite helpfull there
<FunkyPenguin>
what's the correct usage for build.sh? if i try and run it in the lichee-3.3/sun7i-dev it complains with "Please run at the top directory of linux-3.3" when im in the root of the repo already
<foubarre>
oliv3r: looks like the sunxi-bsp easy option will not make it. "no rule to make mk802-1gb_config".. and this board exists in the ./configure list..
<foubarre>
oliv3r: in that case, is it possible that even the manual build and installation fail too?
<foubarre>
oliv3r: Otherwise, i'll go that route.
<luoyi>
with arch linux 3.0's config file, I'm compiling the linux-sunxi 3.4 source, and get the error: http://pastebin.com/EJ8KtJ7r
<oliv3r>
i assume the Vrms I wrote is a consequence of the freq.
<oliv3r>
so probably unrelated
<oliv3r>
but we should be relate bits to devisor
<oliv3r>
especially the 48, 32, 20 and 6 MHz, which relate directly to only 1 bit set
<oliv3r>
48 MHz probably is the base clock
<oliv3r>
probably some multiplication that makes things a little more difficult maybe
<oliv3r>
Turl: should know easily :p
<oliv3r>
foubarre: something may have gone wrong, but the 'configuration' is simply which fex file to build/use
<mripard>
bfree: I did so this morning
<oliv3r>
foubarre: so you can always choose one that's simpilar, mk802 with a10; use cubieboard, don't use the script.bin and u-boot and your fiine
<oliv3r>
mripard: did what?
<bfree>
mripard: ooooooops, sorry ... and thanks (for everything not just this) :-D
<mripard>
bfree: but you were right :)
<mripard>
oliv3r: send the emac patches
<oliv3r>
a link to a mailing list
<oliv3r>
if you could be so kind :)
<oliv3r>
or subject I can google for
<mripard>
they didn't change except for the typo you saw
<oliv3r>
ohh
<oliv3r>
i thought hno's initialization fix would be taken into account
<oliv3r>
wanted to review it! :D
<oliv3r>
it might not matter too much, but it would lead to incorrect frequency of the MDC until it's properly initilized
<mripard>
oliv3r: I've not really followed what happened to you, but it can always be fixed as a followup patch
<oliv3r>
mripard: what ml should I look for the patch? lakml?
<mripard>
lakml, lkml, netdev
<oliv3r>
cool, i'll look at lakml
\\Mr_C\\ has joined #linux-sunxi
<foubarre>
oliv3r: i'm on a real mk802. No cubie at the moment. (winting a bit to see if the A20 version announce comes out)
<foubarre>
-n+a
wingrime has quit [Ping timeout: 240 seconds]
wingrime has joined #linux-sunxi
mab_ has quit [Ping timeout: 252 seconds]
<mnemoc>
foubarre: first the prototypes for sunxi devs to get free software support. then to the masses
<oliv3r>
foubarre: doesn't matter the same kernel runs on all A10 devices
<oliv3r>
foubarre: the reason we have a board selection is, SPL depends on certian settings that are board (DRAM actually) specific; and to choose the right script.fex
<oliv3r>
the kernel itself, is identical for all a10 devices
* mnemoc
eager to tell the same about all a1x devices
<foubarre>
oliv3r: thanks for the info.
mab_ has joined #linux-sunxi
wingrime has quit [Ping timeout: 260 seconds]
wingrime_ has quit [Ping timeout: 252 seconds]
<PiyushVerma>
ssvb : as I mention early cpu overclock of cedar not help
<PiyushVerma>
ssvb: I am sorry that was xfce a linux distribution
<specing>
xfce is not a linux distro
foubarre has quit [Ping timeout: 248 seconds]
<ssvb>
PiyushVerma: then I guess there must be some other reason for the video playback slowness
\\Mr_C\\ has quit []
mab__ has joined #linux-sunxi
<ssvb>
PiyushVerma: mali is useful for 3d applications and also for desktop effects in the gles accelerated compositing window managers
mab_ has quit [Write error: Connection reset by peer]
<ssvb>
PiyushVerma: you can use kwin_gles with xfce if you want wobbly windows
<PiyushVerma>
ssvb: yes but if some ready to use info will be faster
<PiyushVerma>
I want any light waight window manager with mali
<PiyushVerma>
ssvb: one new news
<PiyushVerma>
ssvb: If i stop audio same video work perfectly
<PiyushVerma>
I try to creat artificaial load for cpu but still video work fine
<PiyushVerma>
now sure how audio effect video. any idea ?
hglm has quit [Read error: Connection reset by peer]
<ssvb>
maybe video/audio synchronization is somehow messed up
wingrime has joined #linux-sunxi
<ssvb>
as cedarx libve does not handle audio, it looks like the media player is to blame
<PiyushVerma>
it all our media player
<PiyushVerma>
all our coding
<PiyushVerma>
we use ffmpeg to decode audio
wingrime_ has joined #linux-sunxi
<Turl>
oliv3r: I had a v1.20... which is labeled 3 days *after* 1.21 wtf :)
hsildaerD is now known as Dreadlish
Dreadlish has quit [Changing host]
Dreadlish has joined #linux-sunxi
<Turl>
oliv3r: ahh, yours is a datasheet, that's why
<Turl>
mripard: did you get the gpiolib patch merged for the -rc?
wingrime has quit [Ping timeout: 248 seconds]
<PiyushVerma>
ssvb: there is some reserved memory for cedar
wingrime_ has quit [Ping timeout: 276 seconds]
<PiyushVerma>
any idea how to increset that ?
<PiyushVerma>
I want to cache decoded frame
<mripard>
Turl: I was planning to do the pull request tonight or this weekend
<ssvb>
PiyushVerma: it is set by "sunxi_ve_mem_reserve=80" option in the kernel command line, replace 80 with whatever you like better
mab__ has quit [Read error: Connection reset by peer]
<ssvb>
what do you mean by "cache decoded frame"?
<hramrach_>
ssvb: audio sync is black magic
<hramrach_>
mplayer is very particular about sync but it does not work with alsa nad pulse most of the time
<Turl>
mripard: great, thanks
<hramrach_>
some other players use different synce methods which can cope with something as abysmal as alsa or pulse but may trade that for worse sync
wingrime has joined #linux-sunxi
<hramrach_>
also we don't have much choice on sunxi
\\Mr_C\\ has joined #linux-sunxi
wingrime_ has joined #linux-sunxi
<hramrach_>
there is only alsa driver for the audio unless you are willing to plug in an USB/BT card
<hramrach_>
and mplayer does not have accel so cannot be expected to decode the video part
<hramrach_>
but you can try the oss emulation of alsa at the very least and vlc vs xbmc
<Turl>
mripard: hmm, you didn't fix either of the issues I was having with emac v3 :p
<mripard>
Turl: that's why you have to email me things like that :)
<mripard>
now, I guess you have another opportunity to do so
<hramrach_>
ssvb: as for caching decoded frames - the decoder may need old frames but presumably caches them internally if configured correctly. I don't see much more sense in caching unless you wanted something like thumbnails for seeking but that's up to the player to get and keep up to date
<Turl>
mripard: ok :)
<hramrach_>
PiyushVerma: what would you want the cached frames for?
<mripard>
Turl: reply with the patch directly, I'll take it and merge it
<PiyushVerma>
Usualy in playback they are in differnt thread
<hramrach_>
you can look up the code for making thumbnails in xbmc - that's pretty much caching decoded frames
<PiyushVerma>
like container read thread decode thread & render thread
<PiyushVerma>
if any process delay it not effect much on other side
<PiyushVerma>
but in cedar it decoded and rendered in thread
<PiyushVerma>
any small delay can effect lag
<PiyushVerma>
if we cache 10 frames and decode and render in different thread
<PiyushVerma>
then it can minimise lag
<PiyushVerma>
ssvb : what u think for this ?
<hramrach_>
you want like decode several frames in advance and show them when the time comes they should be on screen?
<PiyushVerma>
hramrach: right
<PiyushVerma>
that will prevent lag if decode is delayed
<ssvb>
there is always going to be some decoding lag, you probably just need to also delay the audio a bit
<hramrach_>
if the lag is temporary - eg. on decoding the key frames it might help
<ssvb>
and not attempt to speed up the video which might be impossible
<PiyushVerma>
rogjt
<PiyushVerma>
right
<PiyushVerma>
cause I did some test we are able to decode fullhd fram in 15ms
<PiyushVerma>
and display in 8 ms
<PiyushVerma>
total 23 ms
<PiyushVerma>
very close to 33 ms
<PiyushVerma>
any delay will cause lag
<PiyushVerma>
if we devide in thread
<PiyushVerma>
then the max of 15 + 8 would be only 15 ms
<hramrach_>
a frame is going to take up about 8MB of ram so to store 10 you need ~80MB
<PiyushVerma>
if could buffer that other delay also could be recovred
<PiyushVerma>
well I cant cache more than 5 it crash
<hramrach_>
and 10frames is like 300ms worth of video
<PiyushVerma>
sorry more than 3 it crash I think
<PiyushVerma>
don't know why
<hramrach_>
where do you cache them?
<ssvb>
PiyushVerma: btw, is this 15ms time per frame constant regardless of the VE clock frequency?
<PiyushVerma>
did not test with changing clock
<hramrach_>
PiyushVerma: you know what clock you get?
<PiyushVerma>
before was some example code now can't find in libcedar
<PiyushVerma>
may be I need to update then can discuss
<hramrach_>
I can give you a kernel patch that kprintf()s the clock
<PiyushVerma>
when chnge clock ?
<PiyushVerma>
I already change kernel and forse it for 260Mhz
<PiyushVerma>
I already change kernel and forse it for 360Mhz
<hramrach_>
clock is set up when libve is setting up cedar to decode
<PiyushVerma>
I ignore any further change request in ioct
<PiyushVerma>
so it alwase be 360 Mhz
<hramrach_>
the highest clock supported by the current kernel code is 960MHz/3 which would be 320MHz
<PiyushVerma>
sorry my mistake then it would be 320 Mhz
<hramrach_>
but cedar on Linux always asks for 240 and 180 on android
<PiyushVerma>
I devide by 3
<hramrach_>
at least with videos I tried
<PiyushVerma>
is there any repository online which have basic h264 playback code ?
<hramrach_>
basic playback using cedar?
<PiyushVerma>
yes
<hramrach_>
that would be the vlc and xbmc code
<hramrach_>
in vlc it's in a separate plugin
<PiyushVerma>
aah those huge
<hramrach_>
but it uses a lame wrapper library
<PiyushVerma>
I have some very simple and small test code
<PiyushVerma>
where we can seperately test each module
<PiyushVerma>
display driver have a accelerated rendering api
<PiyushVerma>
which use to render decoded frame
<hramrach_>
you cannot really run the one vlc output module but the code for dealing with cedar is in that module only
<hramrach_>
presumabl xbmc has something similar
<PiyushVerma>
ret = vs->hcedarv->decode(vs->hcedarv);
<PiyushVerma>
this code decode fram
<PiyushVerma>
then we check if it got fully decoded frame caus some time raw data not enough to get decoded picture
<PiyushVerma>
ret = vs->hcedarv->display_request(vs->hcedarv, picture);
<PiyushVerma>
I assume decode function decode in ring buffer
<PiyushVerma>
right ?
<hramrach_>
should not be too difficult to make an application based on that code that dumps the frames to disk and writes statistics about decoding time
<PiyushVerma>
right
<PiyushVerma>
we did that
<PiyushVerma>
so we know decode and render time
<PiyushVerma>
may be I create a git repository and push my basic test program
bsdfox has quit [Ping timeout: 264 seconds]
<hramrach_>
at 35 fps you get like 28ms for a frame but most videos are 25~30 fps
<PiyushVerma>
right
<PiyushVerma>
but there are many unexpcted delay
<hramrach_>
so 23ms decode&display time is not bad
<PiyushVerma>
which need ot hendle properly
<PiyushVerma>
for that need queue
<hramrach_>
did you time a piece of video to see if the decode time varies?
<hramrach_>
you cannot really acount for diaply delay. it would be caused by system load and any anount of caching would not speed it up
<PiyushVerma>
not remember
<hramrach_>
I can give you some video samples that seem hard to decode so you can time those or I can time them if you push the app
<PiyushVerma>
ok
<PiyushVerma>
plase give me I test
Yaku321 has quit [Ping timeout: 248 seconds]
<hramrach_>
ok, I try to clip a bit longer chunk than 10s
<PiyushVerma>
k
Yaku321 has joined #linux-sunxi
<PiyushVerma>
one other question
<PiyushVerma>
I know sdk not allow to get pointer of a texture in Mali 400
<PiyushVerma>
But android have that feature
<PiyushVerma>
Any idea that if possible to get point of a texture in GPU
<hramrach_>
it can work with files > 10M, unlike github
<mnemoc>
spanish service with a name that means "cut me in steaks" in spanish. don't want to know what was the original intention of the guy for the domain
<Turl>
mnemoc: I used it a couple of times but it never works "just right"
<mnemoc>
it's a proxy on a crappy server. but does the job
<hramrach_>
I know no spanish and it makes different sense in english ;-)
<hramrach_>
either way it seed to work last time
<hramrach_>
seemed
<hramrach_>
meh
<mnemoc>
i makes no sense in english at all, beside the "file" at the begining :p
<mnemoc>
but "fileteame" is a word on itself in spanish. and it's hosted by a company on my town, here in spain.
<mnemoc>
hramrach_: want sftp access to dl.linux-sunxi.org?
<mnemoc>
to share your files I mean
<drachensun>
I have heard you mention this before, it is obviously bugging you
<mnemoc>
hramrach_: paste me your ssh public key on /q
<drachensun>
you should knock on their door and ask whats with the name
<mnemoc>
drachensun: :D
<mnemoc>
drachensun: it's a pretty disturbing name
<mnemoc>
drachensun: but it might also be related to the fact that they only hire gnome people :(
<mnemoc>
i mean. the feeling
<ssvb>
hramrach_: your sample plays just fine with vlc, but is choppy with xbmc
<ssvb>
hramrach_: does not look like cedarx hardware fault
<Yaku-noob>
are you all working with the same linux image atm ?
<drachensun>
gnome aye, with the weird name thats 2 strikes
ganbold_ has joined #linux-sunxi
<PiyushVerma>
some time USB Uart very painfull
<PiyushVerma>
some time it work without issue and some time unable to enumerate USB Device
<hramrach_>
ssvb: which one?
<hramrach_>
the 1080p or the 720p?
<ssvb>
hramrach_: 720p, it looks like it has 6 channel flac audio, this probably could cause troubles for xbmc
<hramrach_>
ssvb: it played very poorly on vlc for me too
<hramrach_>
but not at the screen atm so can't tell
<ssvb>
hramrach_: transcoded Sintel trailer to use flac audio (just 2 channels though), feels kinda choppy in xbmc even though not as bad as a slideshow
hglm has joined #linux-sunxi
<hramrach_>
mnemoc: File is a word and Tea is a word. It's even capitalized that way ;-)
<mnemoc>
hramrach_: File Tea Me ? :p yes, words. but no meaning
<mnemoc>
so my brain is stuck with the disturbing spanish meaning :(
<hramrach_>
me looks like random cheap domain
<hramrach_>
it's not included in the name on the web
_BJfreeman has joined #linux-sunxi
<hramrach_>
talking about weird software names
_BJfreeman is now known as BJfreeman
<hramrach_>
you know the libupskirt saga?
<mnemoc>
o_O
<mnemoc>
no... /me googling
<hramrach_>
read some article about the rather controversial history of that name
<Turl>
mnemoc: go look up libcaca and libpr0n
<hramrach_>
libpr0n is rather obvious but I have no suspicions about libcaca
<Turl>
you need to know spanish or similar
<hramrach_>
my spanish is limited to like 5 words
<mnemoc>
hramrach_: it's libcrap in english
<hramrach_>
it serves it right
<hramrach_>
never got decent output with that thing
<Turl>
hramrach_: go look at the logo on the webpage
<hramrach_>
:D
<hramrach_>
as favicon it's too small to tell apart from mini-cthulhu
<ssvb>
wingrime: try to add some code to vlc into the part which manages buffers allocation, and print the addresses
<wingrime>
that buffer 0x040000 are reserved on boot
<ssvb>
reserved for VE?
<wingrime>
and yes
<wingrime>
VE need "big lineral space"
<ssvb>
yeah, physically contiguous memory is needed for many HW accelerators, I guess that's why VE gets 80MiB reservation on boot
<wingrime>
yes
<wingrime>
and according traces
<wingrime>
it make 3 general buuffer
<ssvb>
this buffer is used as a heap for smaller allocations on per needed basis, you need to track these individual allocations and check how they are related to the addresses in HW registers
<ssvb>
have a look at mem_palloc
<wingrime>
I need something like gdb
<ssvb>
just add debugging print to the functions like mem_palloc and mem_pfree
<ssvb>
also it's a good idea to start with some simple codec, get a bit of understanding how it works (by checking some software decoder), and then try to see if there are any similarities in how it is handled by cedar
<dwilkins>
oliv3r: yt? What about the pwm patch?
<PiyushVerma>
ssvb: I think step would be similer to samsung
<PiyushVerma>
which we discuss early
<PiyushVerma>
not needed depth understanding for codec
<wingrime>
ssvb:mpeg4 simple
<wingrime>
comp others
<ssvb>
mpeg2 is even more simple
<wingrime>
mpeg124 are use same engine
<ssvb>
PiyushVerma: some basic understanding about the high level data flow is still needed
<PiyushVerma>
ssvb: what question in ur mind may be I can ans ?
<PiyushVerma>
Regarding codec
<ssvb>
not sure about your question
<ssvb>
wingrime is trying to reverse engineer cedar hardware to understand how it works and document it (at least as the first stage)
<PiyushVerma>
ok
<ssvb>
the codecs are not that difficult and there are open source implementations available, tracing these open source implementations and comparing results with the trace of cedar can provide some valuable information
<PiyushVerma>
I my samsung early experiance
<PiyushVerma>
all processing happen internely hardware layer
<PiyushVerma>
outside we pass raw encoded data
<PiyushVerma>
and call a sfr
<PiyushVerma>
then wait for interrupt
<PiyushVerma>
and read decoded data
<ssvb>
but the raw encoded data is still split into frames?
<PiyushVerma>
right
<PiyushVerma>
that is job of container parser
<PiyushVerma>
not done by cedar
<ssvb>
yes, but it is passed to cedar somehow
<PiyushVerma>
In my case
<PiyushVerma>
I pass each NAL frame to decoder
<PiyushVerma>
and it decode and give me result
<PiyushVerma>
in cedar
<wingrime>
by frames, or macrocells?
<PiyushVerma>
frame
<PiyushVerma>
macrocells take care by hardware decoder
<PiyushVerma>
and I don't think even libcedar have any code related with that
<wingrime>
you mean that does not care that B or P frame is?
<PiyushVerma>
it's all done by hardware layer
<PiyushVerma>
ret = vs->hcedarv->request_write(vs->hcedarv, packet.size, &buf0, &bufsize0, &buf1, &bufsize1);
<wingrime>
very look like config-> do, config -> do
<PiyushVerma>
right
<PiyushVerma>
this is one decode call ?
<wingrime>
reset mpeg to reset mpeg
<oliv3r>
wingrime: i like your trace up on the wiki; did you use ... frogot his name's use of valgrind tool thing?
<oliv3r>
wingrime: maybe really nice to have would be a discription how to obtain/use those tools, what it generates, so that others can do it too
<wingrime>
oliv3r: this is valgrind
<wingrime>
may be late
PiyushVerma has quit [Quit: Konversation terminated!]
awafaa_ has joined #linux-sunxi
<oliv3r>
Turl: well all information should be relevant ;)
<oliv3r>
Turl: sunxi-next is what we should write new stuff against? I would hope so ;)
steev has joined #linux-sunxi
steev has joined #linux-sunxi
steev has quit [Changing host]
PiyushVerma has joined #linux-sunxi
<hno>
oliv3r, the 3.4 kernel driver do not have the same MCLK issue. There the MCLK is properly set before MII management bus is registered.
<Turl>
oliv3r: no, you should write it against torvalds/master or whatever other relevant and not rebased tree
<Turl>
oliv3r: is the warning on top of sunxi-next not visible enough? :)
LoCoZeNoz_ZUE has quit [Remote host closed the connection]
Yaku-noob has quit []
<mnemoc>
Turl: or use a tracking branch using sgit ;-)
<mnemoc>
Turl: getting your patches "magically" stacked on top of a rebased sunxi-next
dl9pf is now known as LinuxFoundation_
n01 has joined #linux-sunxi
<mnemoc>
rm: didn't you have an A10S stick with uart?
<rm>
no
<mnemoc>
:(
<rm>
I have a mysterious MK802 which doesn't boot
<mnemoc>
with A10?
LinuxFoundation_ is now known as LF_dl9pf
<rm>
should retry booting it with a recent u-boot sometime
<rm>
yes, A10
vgrade has quit [Quit: leaving]
<oliv3r>
wingrime: PiyushVerma the blob is made from various sources from the internet (See RE page) and then some functions rewritten to invoke the decoder
<oliv3r>
hno: i was speaking of mainline driver, sorry; i think they both where (partially?) written by stephan rose
<oliv3r>
Turl: i hadnt visited the github tree yet :p
<PiyushVerma>
oliv3r: aah thanks for information I will chk it
<oliv3r>
90% of the code that is the blob is existing code frmo the internet
<oliv3r>
wingrime: also, awesome on the wiki RE page :)
<Turl>
rm: check if it has a AXP or not
<mnemoc>
shouldn't that [[Reverse Engineering]] become [[CedarX/Reverse Engineering]] ?
<oliv3r>
lkcl: do you swap out sd cards during that?
<lkcl>
no
<hramrach_>
it's not like the players don't reset the negine
<oliv3r>
lkcl: depends on the card really
<lkcl>
loovelyyy
<lkcl>
that good eh?
<oliv3r>
i know on my pie, with a bad power supply, some SD cards simply refuse to work reliably
<lkcl>
jaezuss
<lkcl>
ok.
<oliv3r>
some don't work at all; it's really really flakey
<oliv3r>
so don't trust the sd card (or the A10)
<lkcl>
ok hmmm.... earth lead....
<oliv3r>
could even be some noise on the MMC traces on the pCB (unlikly, but not entirly impossible)
<lkcl>
wire.... wire...
<oliv3r>
could be a pure software issue to :p
<oliv3r>
but the 'mmc0 detect change' during power is a bit odd
<wingrime>
hramrach: you need read some reg with that tool....
<wingrime>
you actualy do ?
<lkcl>
oliv3r: i've done boot-over-usbfel before
<lkcl>
and then it's absolutely fine.
<lkcl>
detect, remove, re-insert: all good
<oliv3r>
hno: is there a reason we overlock the MDC per default? I read 2.6 MHz now :p
<oliv3r>
so this is the first time booting frmo?
<oliv3r>
try a different sd card :)
<lkcl>
oliv3r: from sdcard yes.
<lkcl>
mmm ok
<lkcl>
well what's really weird is that u-boot is loading the uImage that the kernel's bloody well booting!
<lkcl>
good, eh? :)
<lkcl>
over the *same* mmc!
<oliv3r>
hehehe, well, theoretically, different driver :p
<oliv3r>
do you have a cubieboard handy? use that to test; SD card should work just as well
<lkcl>
true.
<lkcl>
naah.
<mnemoc>
evil chinese board
<oliv3r>
anything A10
<lkcl>
:)
<mnemoc>
luke's is british :)
<mnemoc>
like the pi :p
<lkcl>
mnemoc: don't push yer luck :)
<mnemoc>
*g*
<lkcl>
swearing like that. honestly
<lkcl>
wash yer maaath out wiv soap!
<mnemoc>
for telling the pi is brit, or eoma68-a10 is brit? :)
* mnemoc
better shuts up
<oliv3r>
OR ,that lkcl is a brit
<oliv3r>
it's like a british party here
<lkcl>
ha ha
<oliv3r>
tea gov'nor?
<oliv3r>
one lump or two dear
<lkcl>
o dear
<lkcl>
fucking sdcards.
<lkcl>
fucking fucking sd cards
<mnemoc>
fel-boot?
<oliv3r>
lkcl: diff sd card works?
<oliv3r>
doesn't have to be sd card
<lkcl>
oliv3r: yep.
<oliv3r>
could be bad pcb tracing, clock noise, trace noise etc
<lkcl>
different sd card
<lkcl>
1sec
<oliv3r>
but as I said, they can be highly picky
<mnemoc>
both of my CB and my a13-olinuxino came with not functional uSD slots.... until I blowed them
<lkcl>
grrrrrr
<lkcl>
i think i know what it is
<lkcl>
maybe
<oliv3r>
hno: ok looks like mii clock was always overclocked. Guess the phy can work safely at 2.66 MHz, I suppose 2.40 MHz would be within limits however?
<oliv3r>
mnemoc: NOT functinoal? and when you blew them up they worked?
mdfe has quit [Disconnected by services]
<mnemoc>
oliv3r: just. evil chinese dust
<mnemoc>
s/just/yup/
mdfe_ has joined #linux-sunxi
tinti has quit [Ping timeout: 246 seconds]
<lkcl>
fucker.
<lkcl>
fucking works now.
<lkcl>
:)
<lkcl>
right voodoo magic boot.sc
<lkcl>
right voodoo magic boot.scr
<hramrach_>
wingrime: I read reg 0
<oliv3r>
mnemoc: how did you blow it up?
<oliv3r>
lkcl: your welcome :)
<mnemoc>
slowly
<lkcl>
taaa oliv3r
<mnemoc>
oliv3r: btw, I mean "blew" not "blew up" (boom)
<oliv3r>
oh, dust
<oliv3r>
oh
<mnemoc>
yes, just dust
<oliv3r>
Turl: is it possible, that during u-boot,t he CPU runs off of PLL1?
<mnemoc>
don't know who first recommended that to me. but worked on the other boards too
<oliv3r>
hno: i've tested all other bits, nothing does anything. so after we figure out the devisor, isntead of always setting it to 2.6 MHz, maybe 'look' at the AHB freq. and based on that, set the mac cfg?
<Turl>
oliv3r: uboot reconfigures the cpu clock, so you won't get the default
<oliv3r>
Turl: so is it very likly that u-boot runs of PLL1?
<Turl>
yes, from what I recall, if axp config was successful or it's a no axp board, uboot switches to pll1 for cpu oliv3r
<oliv3r>
ok, just double checking
<Turl>
hno should be able to confirm
<Turl>
oliv3r: is the freq related to ahb then?
<oliv3r>
yep 100%
<oliv3r>
emac's mdc doesn't have a 'clock select' however
<oliv3r>
unless that also runs at ... 24? 12? MHz
<oliv3r>
i think ahb runs default at 24 /2?
<oliv3r>
ah, no 24/1
<Turl>
nah, should be way higher
<oliv3r>
so 24 MHz for AHB then
hipboi|cubie has quit [Ping timeout: 260 seconds]
<Turl>
when running from pll1, ahb should be.. let me check
<Turl>
*Description: set target frequency, the frequency limitation of axi is 450Mhz, the frequency
<Turl>
* limitation of ahb is 250Mhz, and the limitation of apb is 150Mhz. for usb connecting,
<Turl>
* the frequency of ahb must not lower than 60Mhz.
<Turl>
oliv3r: I also wonder how does my wemac work when I'm changing the ahb freq continuously with cpufreq :P
<oliv3r>
emac*
<Turl>
meh, nitpicker :)
<oliv3r>
my phy is broken :p
<oliv3r>
i should boot android and change frequencies to check
<oliv3r>
also, this is MII communication freq
<oliv3r>
at higher freq. it fails :p
<oliv3r>
well all i know, with bits set to 0b000 and 0b001 it's 48 MHz, and 0b1111 it's about 2.18 MHz
<Turl>
which bits?
paulk-desktop has quit [Quit: Ex-Chat]
<hno>
Turl, emac is using another clock. It needs a quite exact clock. Not sure how it's derived.
<hno>
Turl, the bits oliv3r is talking about is the emac MCFG register which configures the MII managemend bus clock.
<hno>
oliv3r, both my cubie and mele seems to work fine with overclocked MII management bus.
nove has quit [Quit: nove]
<vinifm>
I realized that not possible to playback video using libvlc with libcedarx
<hno>
and yes, u-boot SPL configures the CPU clock to use pll1 @1008MHz, and matching AXI/APB/AHB divisors.
<oliv3r>
hno: well i was poking at the mcfg register, and only those 4 bits are of interest. i documented the frequencies it produces changing the bits
<oliv3r>
hno: also, changing the AHB bus, changes the 'base' MCFG freq.
<oliv3r>
so they are directly related
<hno>
It does?
<oliv3r>
hno: yeah
<hno>
Does it also change if you change APB clock?
<oliv3r>
yeah gcc probably optimizes that, so * 8 is probably logically
<oliv3r>
hno: i'm using the SD spl
<oliv3r>
same result, rebuilt spl
<Turl>
oliv3r: if you use whatever you have on nand, does it work?
<oliv3r>
the PHY, no; but i have stock android there
<oliv3r>
is there a very easy way to check things from stock android (I do have terminal.apk installed)
<hno>
oliv3r, what you want to check?
<oliv3r>
if under android those registers are in 'safe' mode
<oliv3r>
i can check mdc pin though; let me do that
dragonn has quit [Ping timeout: 256 seconds]
<hno>
just stop NAND u-boot and print them. Ot watch what boot1 says.
<oliv3r>
3.5 MHz during nand boot
<oliv3r>
1.5 MHz after wemac start
<oliv3r>
833 khz now
<oliv3r>
possible cpu downscaling
<Turl>
oliv3r: move around on android menus and open apps
<oliv3r>
ok
<oliv3r>
ermneed to find mouse
<hno>
or reboot and watch boot1 output and explore registers from NAND u-boot.
<hno>
that way you know without any guessing.
<oliv3r>
booting nand u-boot now
<oliv3r>
2.33 MHz was the highest MDC was at during use of android
<oliv3r>
moving around stuff, starting apps etc
<oliv3r>
833 kHz was the lowest
<oliv3r>
but it did change based on CPU (AHB) freq
<oliv3r>
01c20000: a1005510 .U..
<oliv3r>
01c20054: 00020311 ....
<oliv3r>
MDC pin is 'high' though No clock at all
<oliv3r>
Turl: while shorter, it's more 'mathy'. i think gcc will optimize both structures to about the same, so that shouldn't be a difference. I find the big version a little easier to read, but I do like your version. what version is 'better' however, or more appreciated upstream?
<hno>
hmm...
<hno>
why do the AXI/APB/AHB divisors differ between SPL and Allwinner boot1...
<hno>
It's ok that the MCLK is off. There is no emac support in Allwinner u-boot so it has not opened the EMAC AHB gate.
mturquette has quit [Ping timeout: 240 seconds]
n01 has quit [Read error: Operation timed out]
rz2k has quit []
<oliv3r>
let me see if i can manually turn on the emac
<oliv3r>
well the gateing to it
<oliv3r>
gate is on! :(
<oliv3r>
guess there's no quick way to enable it in aw-u-boot
<hno>
I don't get why 01c20054: 00020311. That's not what boot1 prints. [ 0.180] axi:ahb:apb=3:2:2
<hno>
311 is 2:2:8
<oliv3r>
let me read the boot1 output
<hno>
I see the same here.
<hno>
well, not the safe boot frequency when using our u-boot but the same when using allwinner boot1.