Renard has quit [Read error: Connection reset by peer]
jinzo has quit [Quit: Leaving]
Faisal has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.0]
Andy-D has quit [Ping timeout: 260 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
mmarker has joined #linux-sunxi
eagles0513875 has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
ccube has quit [Remote host closed the connection]
ccube has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
eagles0513875 has quit [Ping timeout: 246 seconds]
froese has quit [Ping timeout: 252 seconds]
physis_ has joined #linux-sunxi
physis has quit [Ping timeout: 240 seconds]
zeRez has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
zeRez has quit [Ping timeout: 272 seconds]
physis_ has quit [Remote host closed the connection]
bengal has joined #linux-sunxi
zeRez_ has quit []
zeRez has joined #linux-sunxi
sehraf has joined #linux-sunxi
lerc has quit [Ping timeout: 268 seconds]
bertrik has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
zeRez has quit []
lerc has joined #linux-sunxi
cubear has joined #linux-sunxi
bonbons has joined #linux-sunxi
<oliv3r>
bbl
oliv3r has left #linux-sunxi [#linux-sunxi]
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
netlynx has joined #linux-sunxi
<hramrach>
is there any use for meminfo dump from a23 tablet?
oliv3r has joined #linux-sunxi
<wens>
not yet i suppose
<wens>
libv made it to dump all the dram related registers, which is a lot
konradoo87 has quit [Ping timeout: 276 seconds]
konradoo77 has joined #linux-sunxi
deasy has joined #linux-sunxi
MY123 has joined #linux-sunxi
Renard has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 252 seconds]
konradoo77 has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
<oliv3r>
wens: for a23?
<oliv3r>
i made an meminfo-a31 once, but since ha lacked hardware, i gave up on it real quick :)
<oliv3r>
it's a branch on my githubs a10-meminfo fork
oliv3r has quit [Quit: Lost terminal]
Faisal has quit [Ping timeout: 246 seconds]
<netlynx>
Hi all. Is there more documentation and or information available on the TV IN on the A20? (CVBS inputs on the A20). I have not found it on dl.sunxi-linux.org.
Quarx has joined #linux-sunxi
oliv3r has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
konradoo77 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
Andy-D has joined #linux-sunxi
jinzo has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 252 seconds]
konradoo77 has joined #linux-sunxi
Renard has quit [Remote host closed the connection]
froese has joined #linux-sunxi
ganbold_ has quit [Quit: Leaving]
ganbold_ has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
MY123 has quit [Ping timeout: 246 seconds]
physis has joined #linux-sunxi
Andy-D has quit [Ping timeout: 255 seconds]
Andy-D has joined #linux-sunxi
<heffer>
libv: thanks for your help on the wiki page. i've added the external photos plus a photo of the remote now as well http://linux-sunxi.org/Sunchip_SDK-758
physis has quit [Remote host closed the connection]
<libv>
hramrach: yes, we need the dumps
<libv>
hramrach: i will try to send an email in a few h
physis has joined #linux-sunxi
<libv>
hrm, no gpio pins needed for usbc1... our sunxi-3.4 hiccups over that
<wens>
huh?
<wens>
reminds me of my a13 tablet :p
<libv>
but that is the same as the pineriver_h25 :(
<libv>
both should oops the kernel
<libv>
i get round it by disabling the usbc in the .fex
<wens>
put an unused gpio in
<wens>
like power203
hramrach has quit [Remote host closed the connection]
hramrach has joined #linux-sunxi
physis has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 268 seconds]
Andy-D has joined #linux-sunxi
<libv>
yup, looks good
<libv>
thanks, i should go and fix the code to not crash and burn on an empty usb_drv_vbus_gpio
<libv>
heffer: now for some patches :)
<heffer>
libv: yes. working on it :)
<libv>
:)
<heffer>
i will submit a patch for the 512 MB ram version only because i don't have the 1GB version
<libv>
heffer: yeah, sounds like a plan
<libv>
but...
<libv>
here's a little secret
<libv>
uboot detects how much ram is there
<libv>
the value is not used
<mnemoc>
o_O
<heffer>
okay. i won't tell anyone ;)
<libv>
so if the layout is the same, and the timing is the same, there is no difference
<libv>
but start with no appendix to the names indeed
<heffer>
so just submit the patch and fix it later in case the 1GB layout should be different?
<heffer>
ah okay
<libv>
and add _1g for the 1gb version
<libv>
if a change is needed
<libv>
mnemoc: take a 512 mb device
<libv>
mnemoc: edit the dram para to read 1024
<libv>
mnemoc: see uboot detect 512
<libv>
code told me that upon the tpr4 changes for meminfo
<libv>
and yesterday i messed that up on my new a10s device and uboot did the right thing
lerc has quit [Ping timeout: 260 seconds]
<mnemoc>
what if it's the other way around? setting 512 on a 1G?
<libv>
should also just work
<libv>
the size parameter is never used
<mnemoc>
interesting
<libv>
just the 1-2GB SOC max define is used
<heffer>
libv: patches against mainline u-boot are preferred or no?
<libv>
heffer: patches to our sunxi uboot first
<libv>
learn to run first
<wens>
and then fly? :p
<libv>
:)
<heffer>
libv: the projects i usually contribute to prefer patches upstream and then pull changes downstream so i was unsure
<mnemoc>
mortals walk and then run. libv starts running
<heffer>
:D
<libv>
i am a theoretical member of a gliding club :)
<libv>
i am too fat to fly :)
<heffer>
like bumblebees?
<mnemoc>
:D
deasy has joined #linux-sunxi
<libv>
heffer: u-boot-sunxi is our own tree with all sorts of things that are not upstream
<libv>
heffer: like, ~100 devices
<libv>
and i really am too fat to fly, 105kg weight limit on the front seat of an ask-21
<heffer>
ah, okay :)
<libv>
and i am a terrible runner as well :p
<libv>
so i should've actually stated the proper proverb :p
<heffer>
a friend of mine always wants to take me an a trip on a WT-9 Dynamic but together we wouls also bust the maximum takeoff weight
<libv>
:)
<libv>
my old man wants to get a ultralight license... 85kg weight limit in .be, and he's really struggling :) If i weighed that much, people just wouldn't recognize me anymore
<heffer>
but i from what you say i still could go on the front seat of an ask-21 and take a small dog with me :D
<libv>
:)
<libv>
you should see the others, they're often middle aged germans with big round bellies, and they are able to fly, it's just not fair :)
konradoo77 has joined #linux-sunxi
<heffer>
other than the middle aged thing that description would probably be accurate for me ;)
<libv>
:)
deasy has quit [Remote host closed the connection]
wingrime has joined #linux-sunxi
<DagoRed>
Ugh... I found out ALARM doensn't have the HDMI support for it out of the box... I think I need to get that set up for the iteaduino's at lease.
<DagoRed>
*least
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
moofree has quit [Ping timeout: 245 seconds]
<DagoRed>
0
<wingrime>
jemk: are you finaly fixed interlanced?
<jemk>
wingrime: yes, it should decode fine now. deinterlace still not possible, disp is very limited there
<ssvb>
libv: the size of dram is determined by bus width and chip density, the 'size' parameter works more like a comment in the 'dram_para' struct
<ssvb>
libv: and even the bus width and chip density can be runtime detected (in the mainline u-boot but not in u-boot-sunxi)
<wingrime>
jemk: and some news about a80 , it may be possible, but kernel part of cedar are untouched, so thats means we not get any new sub engine
<wingrime>
jemk: that means h265 is included to some engine and on other side it can be implemented on top of GPU
<jemk>
ssvb: any reason why you fixed ve reserved mem size to 80mb in the cma patch and not use the ve_mem_reserve parameter? because the vdr people have problems with too little ve memory now...
<jemk>
wingrime: I'm pretty sure h265 is gpu based, sadly
<ssvb>
jemk: because the 80MB hardcoded limit was originally used by the Allwinner kernel
stingray454 has quit [Remote host closed the connection]
<ssvb>
jemk: and the kernel cmdline parameters were typically (ab)used to reduce memory footprint, sometimes causing troubles for the users
Quarx has joined #linux-sunxi
<ssvb>
jemk: how much would be enough for everyone? can the userland application potentially estimate its memory requirements and communicate this to the kernel?
<jemk>
ssvb: well, 80mb should be enough for video decoding, but vdpau gets the memory for g2d from that area too, and thats too much
paulk-aldrin has quit [Quit: Ex-Chat]
<ssvb>
jemk: ok, do you have a better estimate for the cedar reservation size?
<ssvb>
jemk: I don't quite like these kernel cmdline parameters, because they were a band aid for the absence of flexible memory allocation
deasy has joined #linux-sunxi
<ssvb>
jemk: the users should not normally have any need to touch these
<jemk>
ssvb: isn't cma meant to be used for allocating memory at runtime?
<ssvb>
jemk: yes
<ssvb>
jemk: which reminds me that I have a few patches, which I never sent to the mailing list yet
konradoo87 has quit [Ping timeout: 264 seconds]
Andy-D has quit [Ping timeout: 245 seconds]
<wingrime>
jemk: don't forget you use that memory only for one frame
<jemk>
ssvb: i can't really give a value that suits every need, and if i could it would be that high that i wouldn't want to lose that much memory if i don't need it
<wingrime>
ssvb: if cedar regs configured right way, cedar hw have special irq code when it out of mem
<jemk>
wingrime: ? what do you mean, all decoded reference frames are in that memory
<jemk>
wingrime: no?!
<wingrime>
jemk: I taking about, that blob can copy stream part to lin-mem
<jemk>
wingrime: when the input buffer ends it can trigger an irq, but the main memory usage comes from the decoded pictures
<ssvb>
jemk: we can change the driver to have cedar memory allocated only during the time when it is opened/mmapped, and then add a new ioctl to change the allocation size at runtime
<wingrime>
jemk: yeax , 80mb is pretty big
<jemk>
wingrime: the input buffer is only 1mb, which is enough for everything
<wingrime>
jemk: not in 4k case
<ssvb>
wingrime: but now jemk complains that 80mb is too small :)
<wingrime>
jemk: how much reference planes are required ?
<wingrime>
ssvb: on demand are nice, but not in android case, video should not breakes when no mem are free
<jemk>
wingrime: depends on stream, up to 16 in h264
<nove>
if i am not mistaken, that discussion was caused because of oliv3r asking in the #v4l maillist
<ssvb>
nove: unfortunately the mainline people have no real pressure to deliver any products and can keep bikeshedding forever
<jemk>
nove: thats exactly what i feared. for jpeg/mpeg12 it could work, but h264 is too complex
<nove>
jemk: wingrime, but what it says instead of using as example V4L2_PIX_FMT_H264 for input, we would create a costum format V4L2_PIX_FMT_CEDAR_H264(original bitstream + preparsed info)
ricardocrudo has quit [Ping timeout: 272 seconds]
<jemk>
nove: possible, but v4l2 is a nice, simple to use api. if every soc needs extra pix_fmts it gets a mess
<nove>
jemk: then libv4l could have a api to abstract this
<jemk>
should != has
Faisal has joined #linux-sunxi
mawe242 has joined #linux-sunxi
<nove>
jemk: we are the first, and it looks that discussion was really caused by us
<MY123>
For me, V4L should not manage video encoding. That should be managed by ffmpeg.
<wingrime>
jemk: heh, but cedar not going change so quickly
<wingrime>
jemk: I only figured out that they added direct Yvu decoding (no tiled)
konradoo77 has quit [Ping timeout: 246 seconds]
<wingrime>
cedar is realy reqired for best opensource SoC
<ssvb>
diego71: different Rtt_Nom values may result in rather major changes in reliability, "Output driver impedance" is less important
<ssvb>
diego71: so you can try to compare 0x0, 0x04 (that's what you have now), 0x40 and 0x44
<ssvb>
diego71: 0x0 is less likely to be good, but it's hard to predict anything about the other values
<ssvb>
diego71: what is the revision of your board?
<diego71>
ssvb: rev E
<diego71>
ssvb: actually I have to board rev E, but with different ram chip
<ssvb>
diego71: so this is a board with the 330 ohm RZQ resistor (the DDR3 SPEC suggests 240 ohm), maybe larger Rtt_Nom divisors are expected to work better?
<diego71>
ssvb: like 0x44?
<ssvb>
diego71: or maybe OLIMEX has changed the nominal of this resistor on purpose, specifically to make it work better with the /4 divisor?
<ssvb>
diego71: yes, trying 0x44 would be a good test
<diego71>
ssvb: ok, I start with 0x44...
Andy-D has quit [Ping timeout: 260 seconds]
<ssvb>
diego71: can you upload your current results to the wiki?
<diego71>
ssvb: do you prefer a new wiki page or should I use an existing one?
<ssvb>
diego71: let's see what kind of structure would best to have
<diego71>
nb: at the moment the report.html is 204Kb long... a lot of test, and also dqs_gating_delay randomly changing after some hard reset
<ssvb>
diego71: you should probably go to the "Olimex A20-OLinuXino-Micro Rev.E" page and create a link to something like "DRAM Calibration Results/Olimex A20-OLinuXino-Micro Rev.E/diego71" and paste your results there
<hramrach>
would it work to upload the result file and link to it from the wiki page>?
MY123 has quit [Quit: Quitte]
<hramrach>
the mediawiki can store files but not sure if linking to html would work
<ssvb>
diego71: about the big html file, you can go to the a10-tpr3-scan results directory and pick the subdirectory with the most interesting results
<diego71>
ssvb: like 432Mhz setting that looks stable....
<ssvb>
diego71: that's why it's a good idea to hardcode it in the dram_para struct to some known reliable/most common value
<ssvb>
diego71: but this is only supported in the mainline u-boot
<diego71>
ssvb: in my tests seems stable on normal reboot, bu changing after reset...
<diego71>
ssvb: also... I'm doing test using the linux-sunxi version of uboot. Should I use mainline one?
<ssvb>
diego71: yes, mainline u-boot is better, but it does not work with sunxi-3.4 kernel as-is
<ssvb>
diego71: and sunxi-3.4 is needed for lima-memtester
<ssvb>
diego71: I'll provide an updated u-boot branch later (maybe today)
<ssvb>
diego71: testing 'emr1' should be fine with u-boot-sunxi, except that the random changes of "dqs_gating_delay" may be indeed annoying
<ssvb>
hramrach: the mediawiki setup at linux-sunxi supports html markup, so just a html chunk can be pasted into the wiki directly
<ssvb>
diego71: naturally, if we want to see the effect of changing 'emr1', everything else but 'emr1' needs to be the same for two different runs of a10-tpr3-scan
<ssvb>
diego71: oh, and the 'tpr3' value gets automatically changed, so the initial value from u-boot also does not affect the test results (but the initial 'tpr3' is best to be picked in such a way, that it is stable enough to boot the system)
lerc has joined #linux-sunxi
petr has quit [Ping timeout: 272 seconds]
nove has quit [Quit: nove]
<diego71>
ssvb: result.htmlpasted ...
petr has joined #linux-sunxi
<ssvb>
diego71: thanks! though it seems to be a bit cut off
<ssvb>
diego71: the terminating html tags seem to be missing, maybe this causes it to show "<tbody></tbody>"
<diego71>
ssvb: I suspect I had used an old version of your tools
<ssvb>
diego71: ok
<diego71>
ssvb: I'm going to fix it later. atm is good enough :)
<ssvb>
diego71: yeah, it's fine
<ssvb>
diego71: we will figure out how to best structure the data after we have more test results :)
<ssvb>
diego71: your current setup with 432MHz DRAM / 300 MHz MBUS is the first result in the table :)
<diego71>
ssvb: I've not tested FAST_MBUS configuration, because during the first test, with fast mbus is non stable enough
konradoo77 has quit [Ping timeout: 268 seconds]
<diego71>
(like crashing gcc while compiling u-boot... doh!)
konradoo77 has joined #linux-sunxi
<ssvb>
diego71: increasing the dcdc3 voltage usually helps with the MBUS clock speed, but picking the right 'tpr3' and other settings is also important
<ssvb>
diego71: are you compiling u-boot on the board itself?
<diego71>
ssvb: yes, so I don't have to change the sd (except when something go very wrong)
<diego71>
ssvb: I use a small script that update u-boot on the sd, and then reboot
<ssvb>
diego71: ok
<ssvb>
diego71: in any case, if you got reliability problems with gcc compilation, then lima-memtester should have been able to detect the problems in that setup too
<diego71>
ssvb: i think so, but I didn't even tried. And in that moment, I was not sure what FAST_MBUS was about.
<ssvb>
diego71: it would be really bad if gcc is unstable, but lima-memtester can't see any problems (so we need to keep an eye on that too)
<diego71>
ssvb: when in the future, I'll try to increase mbus clock again, there is preferred way to do it?
<ssvb>
diego71: FAST_MBUS means 400MHz MBUS clock speed in u-boot-sunxi
<ssvb>
diego71: and the mainline u-boot just has 'mbus_clock' property in the 'dram_para' struct
jemk has quit [Quit: leaving]
<diego71>
ssvb: and atm I can't use mainline uboot, because I need kernel 3.4 for lima-memtest, right?
<ssvb>
diego71: yes, the mainline u-boot needs a couple of patches
<ssvb>
diego71: goodnight, see you around later
cubear has quit [Quit: Leaving]
<ssvb>
libv: are any changes needed in the sunxi-3.4 kernel to work nicely with the u-boot display driver?
<libv>
ssvb: it's been soo long, i don't really remember :)
<libv>
yes
<libv>
it needs to know where the memory lives
<libv>
so i nastily introduced some logic to see whether < 16MB was missing off the top of ram
<libv>
also, sun7i clock early pll setting needed to be neutered
<ssvb>
yeah, it probably does not care and just wants to shut down the clocks and reclaim the memory?
<libv>
no, it doesn't reclaim the memory
<libv>
and no, it does not shut down the clocks either
<libv>
on sun7i, some extra fex parsing code was added which set default (fex provided) values for some plls
<ssvb>
what would be the expected behavior that we want?
<libv>
...
<libv>
please rephrase
<ssvb>
we can add some changes to the sunxi-3.4 kernel
<hramrach>
well, it's different from what mainline does. on mainline the clocks are supposed to be left alone but 3.4 would set ehm based on fex?
<libv>
hramrach: sunxi-3.4 only does so for sun7i
<libv>
ssvb: yes, and i have some patches sitting around for myself, as i wanted to try this code on my a10s stick
<ssvb>
libv: so I just wonder if we need or want to do anything to make it more u-boot video driver aware?
<ssvb>
ok
<libv>
ssvb: what is the point of having this on sunxi-3.4?
<libv>
ssvb: i wanted it for early printk and uboot console myself
<libv>
but it was pointless, i should've used fel booting from the start and oggled the usd
Gerwin_J has joined #linux-sunxi
<ssvb>
I mean, I want to have u-boot with the video driver support, and I want to be able to use this u-boot with sunxi-3.4
<libv>
you can, but you just lose 8mb
<ssvb>
if sunxi-3.4 can shut down the clock and reclaim memory, that would be perfect
<ssvb>
and then use the disp driver just like usual
<libv>
ssvb: this simplefb stuff really is everything but simple, now is it
<libv>
and the reason why there was such a big discussion is the fact that the sunxi code showed very clearly that simplefb is a lie
<libv>
it really is denialfb
<ssvb>
there is no simplefb in sunxi-3.4, right?
<libv>
and people are still in denial
<libv>
ssvb: it's trivial to add
<libv>
it's simple, remember :p
<ssvb>
but we probably don't want to, because we already have the disp driver
<ssvb>
and the earlyprintk is probably not worth the efforts
<ssvb>
not much further kernel development is expected on the sunxi-3.4 branch (unless somebody starts merging sun6i stuff), and we already have the serial console
<libv>
well, the whole thing feels like it was not worth the effort tbh
<libv>
u-boot is horribly retarded about anything this millenium
<libv>
and on top of that it treats the cfbconsole pretty stepmotherly
<libv>
so you don't really get a console early
<libv>
you have to load an env before it tries to get you a console
konradoo77 has quit [Ping timeout: 245 seconds]
<libv>
so this whole thing is only half as useful as it is supposed to be
<libv>
and then this whole useless endless discussion because people got shown that simplefb is a lie
Zboonet has quit [Remote host closed the connection]
<hramrach>
at least if u-boot does not fail it should show you kernel messages
<hramrach>
and since it should be possible to get known-working u-boot for most devices it's not that bad
bluse_ has quit [Ping timeout: 268 seconds]
mnemoc has quit [Ping timeout: 246 seconds]
Uninstall_ has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 264 seconds]
bluse has joined #linux-sunxi
ccube has quit [Quit: changing servers]
Uninstall has quit [Ping timeout: 268 seconds]
ccube has joined #linux-sunxi
dl9pf has quit [Quit: No Ping reply in 180 seconds.]
dl9pf has joined #linux-sunxi
dl9pf has quit [Changing host]
dl9pf has joined #linux-sunxi
mnemoc has joined #linux-sunxi
kelvan has quit [Ping timeout: 260 seconds]
kelvan has joined #linux-sunxi
rnp has joined #linux-sunxi
mnemoc has quit [Ping timeout: 245 seconds]
mnemoc has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<ssvb>
libv: I'm too sleepy now to do anything useful right now, but we need to prepare a usable branch for u-boot v.2014.10