hno changed the topic of #linux-sunxi to: /Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See | | Logs at
BJfreeman has quit [Read error: Connection reset by peer]
mcbrick has quit [Ping timeout: 264 seconds]
deasy has quit [Quit: Quitte]
utzig has quit [Quit: leaving]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
deasy has joined #linux-sunxi
naobsd has joined #linux-sunxi
rz2k has quit []
bamvor has quit [Quit: Leaving]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
utente has quit [Quit: Sto andando via]
Offshore has joined #linux-sunxi
naobsd has quit [Quit: Page closed]
shineworld has joined #linux-sunxi
rellla has joined #linux-sunxi
<oliv3r> kernel + u-boot :p support on propraitary binary blobs is limited i'd say
wingrime has quit [Ping timeout: 246 seconds]
hramrach has quit [Ping timeout: 240 seconds]
wingrime has joined #linux-sunxi
hramrach has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
_whitelogger_ has joined #linux-sunxi
_whitelogger has quit [Remote host closed the connection]
rellla2 has joined #linux-sunxi
Quarx has joined #linux-sunxi
shineworld has joined #linux-sunxi
_whitelogger_ has joined #linux-sunxi
n01 has joined #linux-sunxi
vicenteH has quit [Ping timeout: 264 seconds]
rellla2 has quit [Quit: Nettalk6 -]
naobsd has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
atiti has joined #linux-sunxi
FR^2 has joined #linux-sunxi
vicenteH has joined #linux-sunxi
mcbrick has joined #linux-sunxi
atiti has quit [Ping timeout: 268 seconds]
<oliv3r> mnemoc: hansg's tree keeps on growing and growing :( (not your fault, just saying)
<mnemoc> oliv3r: problem is stage/sunxi-3.4 is currently broken (usb)
<oliv3r> yeah, i've heard
<hno> been broken for quite some time I think.
<mnemoc> and hansg's tree only works for a20
<oliv3r> well i'm sure he'll start fixing sun4i/sun5i in his tree asap
<oliv3r> it's a little messy :(
shineworld has joined #linux-sunxi
<mnemoc> imo we need to step back in stage-3.4 and get the usb thing fixed (and problematic/immature) commits removed
<oliv3r> do we know which commit to blame?
<mnemoc> wingrime blames the unification of sunxi-usb
<mnemoc> but i think we can fix the unifiction in a new stage branch
<mnemoc> instead of fully removing it
<oliv3r> i doubt it's 'just' the unification, unification doesn't change that much codewise
<wingrime> mnemoc: if techn returns and fix it
<wingrime> mnemoc: but indeed he mix unification and some Kconfig patches
<wingrime> ML make sence for keep branches unbroken
<wingrime> oliv3r: He broke gadget agian
<wingrime> nomaly branch should builds after every commit, for bisect
<oliv3r> jenkins!
<wingrime> oliv3r: How gate-on something in mainline?
<oliv3r> wingrime: what do you mean? the AHB gates etc?
<wingrime> oliv3r: yes, also ioremap stuff
<oliv3r> i belive you use the clock framework for that? as you enable a clock to a device i would think
<oliv3r> Turl: ^
<oliv3r> wingrime: ther'es 2 gates usually to worry about
<oliv3r> 1 is in the clock registers, that enables the bus clock, the other is usualyl in the device registers
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
atiti has joined #linux-sunxi
hansg has joined #linux-sunxi
<oliv3r> hoi hansg
<hansg> oliv3r, hi
<atiti> hi
rellla2 has joined #linux-sunxi
<wingrime> hansg: hi
<hansg> wingrime, hi
mcbrick has quit [Quit: Leaving]
<wingrime> hansg: Have you noticed hdim-sound hung when you set it on pause with mplayer on a20
<wingrime> mnemoc: ping
<mnemoc> wingrime: pong
<wingrime> mnemoc: I can't find cubieboard PCB trace
<wingrime> *layout
<hansg> wingrime, no I've not tried that
<hansg> wingrime, this is with the latest sunxi-3.4 code ?
<mnemoc> wingrime: the cubieboard is not open hardware. the only we have is
<wingrime> hansg: dma get BUG()
<hansg> and schematics, we've schematics too.
pitillo has quit [Changing host]
pitillo has joined #linux-sunxi
<mnemoc> hansg: wb. i can't pull your branch atm as usb gadget is totally broken :(
<wingrime> hansg: pcb layout
<hansg> wingrime, oh, that is not good (dma BUG)
<wingrime> hansg: also seems to be DMA IP same for a20
<hansg> wingrime, I don't know about pcb layout
<wingrime> hansg: new driver simply add two code layers on top
<wingrime> hansg: but older better
<hansg> wingrime, yes I figured as much, but I did not want to mess with it. Tested patches to switch A20 over to use the old plat-sunxi code are welcome :)
<wingrime> oliv3r: not pdf
<wingrime> oliv3r: scheme itself
<oliv3r> not released afaik
<hansg> mnemoc, in my branch, or in stage/sunxi-3.4, or ?
<oliv3r> so it's partially open hardware :p
<oliv3r> but not really
<hansg> (the gadget broken-ness)
<mnemoc> hansg: both actually.
<wingrime> oliv3r: PCB missing
<hansg> mnemoc, and in sunxi-3.4 non stage ?
<mnemoc> hansg: 1m
<oliv3r> wingrime: not missing, not released :)
<oliv3r> wingrime: ask hipboi to release it!
<wingrime> oliv3r: than it not opensource
<oliv3r> wingrime: it's not really openhardware, but the schematic is available
<oliv3r> so that's why i said partially :p
<mnemoc> hansg: i'll make a full build test now of non-stage 3.4
<hansg> ok
<wingrime> oliv3r: I have my LG phone schenematics
<wingrime> oliv3r: but it not makes it opensource
<wingrime> oliv3r: (looks like it leaked )
<mnemoc> wingrime: LG doesn't fear clones as much as cubietech
<wingrime> mnemoc: it means only omniplex version are fully opensoure?
<mnemoc> don't know what ominplex is. but olimex boards are REAL open source hardware
<wingrime> mnemoc: clones , make clone is orignial opensource idea
<mnemoc> wingrime: that's why I started telling that the CB is not open source hardware
<wingrime> mnemoc: but without verilog files all the crap
rellla2 has quit [Quit: Nettalk6 -]
<oliv3r> wingrime: well the schematic is really all that's needed technically, it's like the datasheet. but yeah, it's not fully open hardware; sad but true
<mnemoc> wingrime: they provide basic schematics and just enough to make extension boards
<wingrime> mnemoc: I can't even prof that there is no backdors
<oliv3r> cubieboard can be cloned extremly easy though, give it a week for a seasoned pcb designer; probably less
<mnemoc> oliv3r: marsboard? :p
<oliv3r> besdies if you wanna clone something cool, there's olimex boards
<oliv3r> it's moot imo
<wingrime> oliv3r: there is some problems with ddr routes
<oliv3r> wingrime: on olimex or cubie?
<oliv3r> cubieboard was designed by the same guy who does the allwinner reference boards
<oliv3r> so ddr traces should be as good as it gets there
<wingrime> oliv3r: both, you can't make own pcb layout without some info about DDR
<mnemoc> wingrime: the cb was designed by an aw ee
<mnemoc> wingrime: olimex's wasn't
<wingrime> mnemoc: nice , but probem also cb2 have 432 Mhz dram clock , olinuxino 384 Mhz
<wingrime> mnemoc: witch means olinuxino will always slower that cb2
<wingrime> notable slower
<oliv3r> or
<oliv3r> olimex uses a safe memory dram clock :p
<oliv3r> i run my olmex at 432 just fine
<wingrime> I think particular reason - ddr traces long
<oliv3r> i think you can do to 480 without problem
<oliv3r> traces look about 2-3 times longer yeah
<oliv3r> on cubieboard the memory chips are much closer to the a20
<wingrime> oliv3r: but it can introduce strange uncatchable bugs
tzafrir has quit [Ping timeout: 276 seconds]
<oliv3r> olimex has restor netowrk between memory chips and SoC
<oliv3r> cubieboard doesn't
<mnemoc> isn't olimex's 4 layer?
<oliv3r> so i think the a20 might be better actually (mor ereliable)
<wingrime> hansg: dma hdmi sound bug
<wingrime> hansg: try play something with mplayer and set it on pause (space key) than if you will try resume you will catch that bug
<wingrime> hansg: but only with hdmi-audio
<Tsvetan> хи
<Tsvetan> oops
<Tsvetan> the reason we made 384Mhz image is, because when we had enough boards produced
<Tsvetan> we noticed that 20% of A20 boards fail on clock more than 400Mhz
<Tsvetan> replacing the A20 chips on them make them alive
<Tsvetan> which made us think that A20 chips have some tolerances and not all can run above 400Mhz
<wingrime> Tsvetan: хи
<Tsvetan> I ask Tom and he observed the same
<Tsvetan> so we decided to generate images with 384 to be on the safe side to all boards
<Tsvetan> 80% of the boards still can run up to 480Mhz
<Tsvetan> btw datasheet say nothing for max safe frequency
<Tsvetan> we found this in fiel
<wingrime> Tsvetan: we still not have any auto testing framework
<Tsvetan> field
<oliv3r> wingrime: you mean for dram timings?
<wingrime> oliv3r: yex, some mistery
<Tsvetan> so running at 400-432-480 may work
<oliv3r> i guess it's with overlcocking a PC, you get it with a safe setting, and then overclock it to whatever works for you
<Tsvetan> but you do not know what tolerances your chips have
<Tsvetan> and when it will fail infield
<wingrime> Tsvetan: are you using same dram ic ?
<oliv3r> Tsvetan: so cubieboard2 also runs at 384 MHz by default now?
<Tsvetan> same memory chips
<Tsvetan> BTW A10 chips do not suffer this problem
<Tsvetan> and work fine on same layout up to 480Mhz
<Tsvetan> so its up to you at what memory clock you want to run your board
<Tsvetan> our statistic though says to stay at 384 to be on the safe side
<oliv3r> better safe then sorry ;)
<Tsvetan> if somebody can run benchmark would be intersting to see how much performance suffer between 384 and 480
<oliv3r> Tsvetan: why did you choose this weird power connector for sata power? The JST 2 pin ones would have been nice (and match the cubieboards making it easier to use those harddisks connectors)
<wingrime> Tsvetan: then you have ddr longer, than you have more chances that their C or L diffences make influence
<oliv3r> Tsvetan: ssvb ran tons of benches, i think he did some of those too
<wingrime> *ddr traes
<Tsvetan> wingrime - have you seen motherboard?
<Tsvetan> the DDR memory pack are at 10-15 cm from the processor
<oliv3r> those traces are long and have a ddr connector inbetween
<Tsvetan> the line lentght is not so crytical ;)
<Tsvetan> the important is the impedance and to make some linesh shorter so the data arrive safely before its clocked
<wingrime> Tsvetan: it depends about pcb material quality , it must have same electical "epsylon" same on whole bloard
<ssvb> Tsvetan: software rendered 2D graphics performance scales almost linearly with dram speed, but this can't be generalized to other workloads
<Tsvetan> wingrime this just affect impedance and you can make same impedance on different materials
<Tsvetan> ssvb: I thouhg the cache is important
<Tsvetan> but you are right when there are graphics there will be lot of memory access and will be related to memory r/w speed
<Tsvetan> I guess A10 is just better designed, or because its manufactured in higher volumes its better debugged than A20 now
<Tsvetan> you know there are always bug at the beginning which are fixed later
<Tsvetan> A10 is produced much more time than A20
<wingrime> Tsvetan: I think motherboard have pcb with good "uniform" electical "epsylon" but cheap FR4 can have difference in epsylon
<wingrime> Tsvetan: it can be different
<Tsvetan> wingrime this is BS
<wingrime> Tsvetan: ?
<Tsvetan> BS = bullshit assumptions for ¨good¨ motherboard materials :)
<wingrime> Tsvetan: ))
<Tsvetan> have to go now, brb
<Tsvetan> OLinuXino it produced on top grade materials with high Tg and controlled impedance
<wingrime> Tsvetan: wait for normal technical disscusion
<Tsvetan> there is no any difference between motherboard and OLinuXino as PCB
<ssvb> Tsvetan: btw, have you tested the maximum CPU clock speed limits for A20?
<wingrime> Tsvetan: have ddr any error correction?
<wingrime> Tsvetan: not good with english physics terms (better explain in russian for me)
<oliv3r> nostradovia
<ssvb> Tsvetan: Tom said that "it should be resolved in the future version of the chip"
<ssvb> Tsvetan: maybe the cpu and dram clock speed can get better eventually after Allwinner debugs these chips
<oliv3r> doubt we'll get a20 rev2
<ssvb> why not?
<oliv3r> i'm sure they'll fix the dramc but i wouldn't be supprised if that goes to a40
<oliv3r> why would they spend engineering time on something that allready 'works'
<wingrime> oliv3r: in terms of physics , it possible that chip will work with 480 but not work with 438 (interfernce ) (VSWR)
<oliv3r> with mediatek and rk breathing down their neck, they are probably working on something that's gonna beat those chips
<ssvb> oliv3r: fixing the number of the CPU cores would be also nice ;)
<oliv3r> :p
<wingrime> ssvb: better get big.LITTLE
<wingrime> oliv3r: LG now produce phones with MTK!
<oliv3r> yeah you said earlier
<hansg> wingrime, I've just mailed a patch to your gmail account for the hdmiaudio bug, please test. Also see the notes in the mail. Thanks!
<oliv3r> allwinner is slowly sinking in obsolesance; they have 1 think strongly going for them and they are messing it up big time. they even pout on their pages 'gpl compatible bla bla'
<oliv3r> MT8135 big.LITTLE
<wingrime> oliv3r: aw such slowpocke
<wingrime> oliv3r: I hope they produce something interesting in recent time
<oliv3r> they have to
<oliv3r> or its bye bye
<wingrime> oliv3r: now there is many fabless vendrors in china
<wingrime> for example
<wingrime> but they have only mips and ARMV6
<arokux1> hi guys
<wingrime> arokux1: hi
rz2k_ has joined #linux-sunxi
<wingrime> hansg: are you tested build with OTG enabled?
<hansg> wingrime, yes
<wingrime> hansg: I have two linking problems with new usb
<wingrime> hansg: have you fixed it?
<rz2k_> hi
<rz2k_> also what usb otg needs to be selected for a20 in hansg tree? new Inventra stuff?
<wingrime> rz2k_: old
<wingrime> oliv3r: there anyone who work on inventra ?
<hansg> wingrime, wait, are you talking about sun7i / A20 builds with otg, that is not supported yet.
<wingrime> hansg: otg with sin4i on your brnach
<oliv3r> hansg: have you tested sun4i/sun5i builds with your a20 tree?
<wingrime> hansg: have you fixed it?
<hansg> wingrime, that should work as long as you select OTG mode not host only, there is a known issue with doing host-only in Kconfig which I still need to fix
<rz2k_> who needs a10 when you have a20 :p
<wingrime> regressions ((
<arokux1> wingrime, you mean USB support?
<wingrime> arokux1: yes
<hansg> oliv3r, yes Im continuously do sun4i/sun5i and sun7i test builds from my tree, as well as the occasional run-time tests on sun4i and sun5i (and sun7i of course)
<arokux1> wingrime, I've started to work on it, but I'm slow.
<oliv3r> hansg: ok good, mnemoc said he was having build issues with your a20 tree
<oliv3r> mnemoc: ^
<wingrime> arokux1: it works some how?
<mnemoc> hansg: sunxi-3.4 (non-stage) passes fine all defconfigs
<hansg> mnemoc, ah, so we're talking about a broken defconfig build, not a runtime issue ?
<mnemoc> problem is in usb gadget mostly, already pulled (untested... meh) into stage-3.4
<hansg> which defconfig is broken ?
<mnemoc> hansg: all of them
<arokux1> wingrime, don't know about 3.4, my goal is to mainline it. but i haven't tried anything so far. was reading the code and comparing allwinner sources with those of inventra.
_BJFreeman has joined #linux-sunxi
<arokux1> wingrime, you are asking because of mainlining?
_BJFreeman is now known as BJfreeman
<oliv3r> arokux1: you are doing otg or host?
<oliv3r> inventra IP is presumably OTG
<hansg> arokux1, why are you looking at inventra sources, AFAIK the otg controller is from Mentor Graphics, and it should be possible to get it to work with the musb code already upstream
<oliv3r> yes! mentor!
<oliv3r> my bad
<oliv3r> and host isn't known what IP that is
<hansg> arokux1, I've compared state-machines between the allwinner usbc0 code and musb, and they are mostly identical
<arokux1> hansg, i've thought Mentor Graphics is the same as inventra..
<hansg> host is simply ohci + ehci, getting that to work should be just adding glue + clock setup code
<arokux1> hansg, ok, but i'm a novice to this stuff, so I haven't went that far yet.
<hansg> arokux1, could be, if you're looking at using drivers/usb/musb then you're looking at the right code
<arokux1> hansg, if you want, you can give me some guidance
<arokux1> hansg, yes, I was looking at this code.
<hansg> mnemoc, ok, I'll put taking a look at the broken defconfig builds on my todo.
<wingrime> arokux1: I also thinking about do DMA and AXP stuff for mainline
<oliv3r> arokux1: i thought you where starting with USB Host code :) would be easier to get started with; and then progress to usb-otg
<mnemoc> hansg: i believe it's broken usb unification
<mnemoc> hansg: not defconfig
<hansg> mnemoc, ok
<oliv3r> wingrime: mdp is working on dma isnt' he?
<wingrime> oliv3r: we have not see any sings of it
<wingrime> for a long time
<arokux1> oliv3r, yes, i also wanted to start with host, why did you thought i wanted otg?
<hansg> mnemoc, right, what I mean is look into fixing the usb code so that the defconfig builds work
<arokux1> hansg, I want to get wifi working in the mainline eventually.
<mnemoc> hansg: it might be better to start a new stage/sunxi-3.4 for now
<oliv3r> mripard_: ^
<hansg> I'm going afk (lunch) back in an hour or so
<oliv3r> arokux1: because mentor/inventra is OTG.
<mnemoc> ok
<hansg> mnemoc, let me first take a look might be easy to fix
<mnemoc> ok
<hansg> really afk now
<mnemoc> cu
<arokux1> oliv3r, ah, ok. frankly, i wasn't able to draw a clear line between the two in the code.
<oliv3r> should be completly different things
<oliv3r> it's like serial and parallel ports :p
<wingrime> arokux1: core code for usb was not writen for linux
<oliv3r> two different IP cores
<arokux1> i'm reading and trying to understand things. i see otg is something completely different. but i wasn't able to find this split in the sources.
<arokux1> wingrime, not written for linux? what do you mean? what core code?
<wingrime> arokux1: OSAL crap
<arokux1> wingrime, OSAL?
<oliv3r> i think usb might be just some ohci/ehci with glue code
<oliv3r> arokux1: usb-otg should be in the drivers/gadget area, wheras 'usb' should be in drivers/usb
<arokux1> oliv3r, driver/usb/host , I think
<wingrime> arokux1: some aw code was shared with aw's melis OS
<oliv3r> arokux1: rgr
<arokux1> wingrime, oh, i see. melis is now dead?
<wingrime> arokux1: not still, sun3i still in market
<arokux1> I see
<rz2k_> iirc Melis is not AW's property
<mnemoc> they even launched new sun3i SoCs
vi390 has joined #linux-sunxi
<rz2k_> oh
<rz2k_> dont they have better target for time to spend
<rz2k_> and also they had signs of WinCE/Windows RT support somewhere
<mnemoc> iirc Melis is AW's fork of a commerical RTOS
<wingrime> mnemoc: PVR, some cheap players , there is some other market shares like PMP, car pc,that not require fastest cpu on share
<arokux1> anyway, I'm working on usb host, but you should know that i'm slow. :)
<rz2k_> then doing an *another* rtos
<arokux1> wingrime, i've thought you were primarily interested in cedarx.
<wingrime> arokux1: so code must be next
<wingrime> arokux1: I also working on it, but now I have(nearly) finished manual for mpeg12/jpeg
<oliv3r> and to be on the safe side, it's probably best if someone else writes it
<oliv3r> someone who didn't do any of the RE work
<rz2k_> now we need a team as large as gstreamer to do the hard work :p
<mnemoc> RE -> wiki -> code
<wingrime> arokux1: thanks jemk we have working jpeg / mpeg12 PoC
<wingrime> arokux1: but still, for mainline kerenl decoding must be done in kernel side
<wingrime> arokux1: we can't map HW registers to userspace
<vi390> hi, does someone know - if when wanting to change screen-resolution on A20 Device (with linaro), changing them in script.bin (nanda) having no "screen0_output_mode" entry in it, can I just create an entry with this name there?
<arokux1> wingrime, just curious, are there standard kernel APIs for that?
<oliv3r> arokux1: nope
<oliv3r> i think the only driver in the kernel that does that is the braodcom crystal hd
<oliv3r> and the radeon should be there now too actually; but not sure if they have some api for it there
<wingrime> oliv3r: also will be nice if you make something like that for MMC and NAND (docs we have no)
<arokux1> but vpdau and vaapi are of the same kind of thing, or? they exist for quite long time already
tzafrir has joined #linux-sunxi
<vi390> i have a [disp_init] entry in script.bin ; is that the same like [screen0_output_mode] ?
<oliv3r> vpdau and vaapi are userspace api's
<oliv3r> vi390: what does the 'fex guide' wikip age say?
<arokux1> oliv3r, but they expose hardware accel. and you want to do it too
<vi390> oliv3r: Ok, found - thx :)
<Turl> hno: mripard_: about FTD & initrd load addresses,
<Turl> FDT*
<rz2k_> vi390: it should be same .fex for disp in A20
<rz2k_> vi390: you can even copy section from one of the fexes around sunxi-boards
<oliv3r> arokux1: ok it's like this, you have some app, say mplayer, that ask libva to decode this stream. libva then does some work in splitting up the bits in proper segments
<oliv3r> then libva has to get those segments submitted to the registers
<arokux1> oliv3r, right. what happens next?
<oliv3r> but we don't do that, because userspace will not talk to registers directly, it asks the kernel to perform certain tasks
<arokux1> oliv3r, ioctl?
<oliv3r> yep, but currently, we have 2 ioctl 'read_reg' and 'write_reg'
<oliv3r> which basically exposes everything to userspace, which is a huge nono
<mnemoc> aw added an ioctl to export the whole register to userspace
deasy has quit [Quit: Quitte]
<arokux1> Turl, good info.
<arokux1> oliv3r, and then the allwinners way is to have user space blob to do the actual work?
<rz2k_> oliv3r: wingrime: just fyi, most of the video encoders/decoders in mainline are v4l2 ones.
<rz2k_> s5p-mfc
<rz2k_> msm-vdenc
tinti has joined #linux-sunxi
<rz2k_> shmobile something
<rz2k_> cant remember others, but these are good examples of mainline drivers for currently kicking SoCs
<oliv3r> Turl: good morning
<oliv3r> arokux1: yep, they used several sources (ffmpeg, libjpeg etc) modified them to work with the registers and blobed it
<Turl> morning oliv3r
<oliv3r> rz2k_: there's other opensource video decoders?
<arokux1> oliv3r, i see.
<oliv3r> rz2k_: ah samsung mfc has closed userspace blob
<oliv3r> iirc
<rz2k_> no
<rz2k_> it has firmware
<rz2k_> loading in, that is in linux-firmware
<rz2k_> you have all rights to use v4l2 calls/ioctls to use this decoder, there's even an example around the net for samsung mfc
<wingrime> rz2k_: we have good side of id, we have no any firmware
<oliv3r> rz2k_: does it have a userspace part? libva/vpdau lib?
<oliv3r> wingrime: well cedarX might be firmware upgradeable
<oliv3r> but we have no idea how, and it's flash, not ram firmware
<rz2k_> libstagefright or something like that for android
<oliv3r> unless they wrote it all in vdhl
<oliv3r> ah of course
<rz2k_> for native linux you have gstreamer examples from some company
<oliv3r> these soc manufactures should just add some upgradable DSP for decoding
<rz2k_> and as i said, it is v4l2 :) you can write whatever you want. that driver gives you calls to allocate memory, place a frame and recieve a decoded frame
<Turl> rz2k_: doubt it's SF, OMX is most likely
<rz2k_> and viceversa
<oliv3r> so when new codec comes, simply write new decoder ;)
<oliv3r> rz2k_: nice one
<oliv3r> then cederus should be v4l2 based aswell
<mripard_> wingrime: pong
<mripard_> Turl: yes, I was following this thread too :)
<wingrime> mripard_: nice to see you now
<wingrime> mripard_: about mailine boot
<Turl> mripard_: so apparently loading over the 128M mark should be safe :)
<wingrime> mripard_: why I have boot it only with base (image-64)?
<wingrime> mripard_: strange xip problem
BJfreeman has quit [Quit: had a good time]
<mripard_> why do you use an XIP image? isn't it only useful on NORs ?
rz2k_ has quit [Quit: time to go home]
<mripard_> Turl: yes, but like I was saying previously, it shouldn't be too high either
<wingrime> mripard_: XIP_KERNEL [=n] , It stange that uImage considered as xip for uBoot
shineworld has quit [Remote host closed the connection]
<Turl> mripard_: in any case, 16M apart as uboot was doing is no good :)
<mripard_> wingrime: how do you generate your uImage?
<mripard_> Turl: yep :)
<wingrime> mripard_: make uImage
Yuuki has joined #linux-sunxi
<Yuuki> wingrime: I got a31 hw CS868
<mripard_> wingrime: the full commandline please
<Turl> mripard_: it looks pretty full to me :P
<Turl> wingrime: are you using LOADADDR=0x40008000 ? notice the 8 in the middle
<wingrime> Turl: yes
ganbold_ has joined #linux-sunxi
<Yuuki> Is there any chance to use Xorg on a31?
<Turl> Yuuki: as long as framebuffer works, you should be able to use xorg with fbdev
<wingrime> mripard_: console=ttyS0,115200 root=/dev/ram0 loglevel=5 panic=10
<vi390> - trying to adjust screen resolution in script.bin on nanda partition. All what I put in there seems to be usesless when rebooting , attached screen still displays "out-of range" can only work on TV Screen, seems not accepting other values like 1024x768 (put them under LCD0) ; any idea why its not working, and maybe how to get it working?
<vi390> every change in script.bin should be read out at a reboot (if stored in the nanda partition) right?
<oliv3r> vi390: what kernel are you using? we kinda only support our own kernels, 3.0 and 3.4 from, in those kernels, you can always override the resolution via EDID
<Turl> oliv3r: yeah but a31 :p
<oliv3r> Turl: but vi390 doesn't say which platform he's using :p
Yuuki has quit [Ping timeout: 248 seconds]
<Turl> oliv3r: ah nvm, confused vi390 with Yuuki :|
<ganbold_> are there A20 registries information somewhere?
<Turl> ganbold_: in Allwinner HQ :P
<oliv3r> lol
<mripard_> wingrime: nah, I mean the full "make uImage" command you're doing
<Turl> mripard_: I make mine with "make uImage", what's wrong with it? :)
<oliv3r> i make mine with sunxi-bsp
<ganbold_> Turl: :D, good answer
<Turl> ganbold_: :)
<vi390> :) Plattform = cubieboard
<vi390> kernel = original :q
<oliv3r> vi390: then you are on your own :p, any reason why you can't upgrade to 3.4?
<vi390> uname -a gives cubieboard2-desktop hmm is that "your" kernel?
<oliv3r> so your using cubieboard2, A20, not cubieboard 1, a10
<vi390> oliv3r: Yes : A20
<oliv3r> cubieboard 2 support is highly experimental
<vi390> hmm, ok
<oliv3r> so your using the lychee 3.3 kernel, which still isn't supported through us, but allwinner
<oliv3r> expect perliminary a20 support to be merged into stage/sunxi-3.4 soon, for now you can use hansg's WiP a20 tree
<vi390> having used the linaro image -as Far as I remember- from sunxi (so you)
<oliv3r> we dont' make linaro images, linaro makes linaro images :p
<vi390> ok :)
<oliv3r> also, the linaro-cubieboard image was made by #cubieboard
<vi390> I see
<vi390> this one did not work ;)
<oliv3r> and they use the stock allwinner 3.3 lychee kernel
<vi390> ok this is maybe then why EDID did not work
<oliv3r> you can try the Hansg fedora 19-r1 image; it works on a20
<oliv3r> we fixed many bugs in our kernels allready :)
<hansg> wingrime, any news on my hdmi-audio fix ?
<vi390> so the fedora 19-r1 has "your" kernel?
<oliv3r> vi390: yep
<mripard_> Turl: without any env variable ? I doubt that would work :)
<oliv3r> i boot mainline without env
Yuuki_ has joined #linux-sunxi
<oliv3r> i nuked my env partition, don't have env.txt nor boot.scr
<Turl> mripard_: well, I export CROSS_COMPILE and LOADADDR on my env setup script :)
<Turl> and ARCH
<vi390> hmm @ fedora ; its using yast and things, hmm I need debian compatible distro unfortunately :(
<oliv3r> vi390: then you can always try to replace the kernel
<mripard_> Turl: yeah, I know, but that's not the point.
<vi390> oliv3r: oh right thats a good idea
<oliv3r> setup fedora on a spare SD; see if it works, change rootfs
<vi390> oliv3r: so you think not being able switching display Modes is most likely caused by kernel 3.3
<vi390> ok @ see if it works, also nice idea. thanks, gonna try
vicenteH has quit [Ping timeout: 256 seconds]
rellla has quit [Ping timeout: 248 seconds]
<oliv3r> vi390: no idea what 3.3 does and doesn't do :)
<vi390> oliv3r: OK :)
Yuuki_ is now known as Yuuki
<Yuuki> Turl: but I getting blank screen using fbdev. Xorg starts successful
shineworld has joined #linux-sunxi
<fluo75> Hi, I am slightly confused which u-boot branch is the correct one for Olimex A20?
<wingrime> hansg: I need configure uboot again for 3.4....
<ssvb> Yuuki: can you see anything on the screen when you "cat /dev/urandom > /dev/fb0"?
shineworld has quit [Remote host closed the connection]
shineworld has joined #linux-sunxi
<ssvb> Yuuki: if yes, then have a look at /var/log/Xorg.0.log after trying to start Xorg to see if there is anything interesting there
<oliv3r> fluo75: sunxi-current should work
<oliv3r> fluo75: how is it confusing you?
<Turl> mnemoc: hansg fixed usb on his tree :)
<Yuuki> wingrime: I got a31 hw CS868 - you asked it 2 days ago
<hansg> Turl, yes, but I'm still tying up some other loose ends. I hope to have something for mnemoc to pull in an hour or 2.
<fluo75> oliv3r, I was convence that it was not yet included in sunxi-current and at the same time, it seemed to be already there... In other words, I manage to confuse myself on this one... :)
<fluo75> oliv3r, thank you very much !!
<Turl> hansg: great
fredy has quit [Excess Flood]
<Yuuki> ssvb: lol... xorg was drawing blank screen. Got it running. BTW it has weird cyan color... Dunno why...
fredy has joined #linux-sunxi
<Turl> Yuuki: using HDMI to DVI cable?
<Yuuki> Turl: direct HDMI
<Yuuki> Turl: without any adapters or gender changers
rellla has joined #linux-sunxi
<Turl> is it all the screen or a bar on a side?
<Yuuki> all screen, even mouse cursor
<Turl> sounds like a colorspace problem, maybe your monitor doesn't like it
<Turl> usually happens with dvi, but maybe it can happen with hdmi too
<Yuuki> is it possible to switch it using xorg.conf?
<Turl> I don't know, I'm not much into graphics, sory
<Turl> ssvb: ^ ?
<Turl> sorry*
<Yuuki> ... also chromium crashes upon startup.... hmmm
<Turl> well, chrome is not exactly well known for its stability :P
shineworld has quit [Remote host closed the connection]
shineworld has joined #linux-sunxi
<Yuuki> I see chromium sigfault like this first time I tested it on several android devices...
<Yuuki> I think it somehow related to weirdness of xorg on a31
deasy has joined #linux-sunxi
<Yuuki> wow... fixed it lol... seems it is incompatible with colordepth 16
deasy has quit [Client Quit]
<Yuuki> colors are normal and chromium do not sigfault with colordepth 24
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
bsdfox has joined #linux-sunxi
\\Mr_C\\ has quit []
<ssvb> Yuuki: you can check if you have scaler mode enabled (16bpp mode is not compatible with it)
<ssvb> Yuuki: it should be somewhere in fex, or alternatively you can try tool
deasy has joined #linux-sunxi
atiti has quit [Ping timeout: 246 seconds]
\\Mr_C\\ has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
<wingrime> oliv3r: nice , dma enigne can offload memcopy
<oliv3r> wingrime: oh that's cool, there was a guy working on improveing memcopy
<oliv3r> forgot his name; hgml?
<oliv3r> wingrime: but is it faster ;)
<wingrime> oliv3r: also we can offload xor and memset
<oliv3r> to dma engine?
<oliv3r> or security engine?
<wingrime> dma engine
<oliv3r> very cool
<arokux1> wingrime, is this special to A10 SoC?
<arokux1> A1X*
<wingrime> arokux1: no , it dma-engine ability
<arokux1> wingrime, by dma-engine you mean hardware or respective kernel framework?
<wingrime> arokux1: kernel framework
<wingrime> arokux1: we have defenetly do memset and memcpy
<wingrime> arokux1: notsure about xor
<wingrime> arokux1: but we have support this
<arokux1> wingrime, interesting how the userspace take advantage of it. should it use special cpu instructions?
<wingrime> arokux1: if it glib supported
<arokux1> wingrime, but how glib takes advantage of this? I mean what kernel API exposes this capability to user space?
<mripard_> wingrime: wow, that's good news
<arokux1> wingrime, and have you meant glibc?
<arokux1> mripard_, thanks!
leowt has joined #linux-sunxi
<wingrime> arokux1: I don't know about userspace
<wingrime> but see CONFIG_ASYNC_TX_DMA:
<wingrime> This allows the async_tx api to take advantage of offload engines for memcpy, memset, xor, and raid6 p+q operations. If your platform has a dma engine that can perform raid operations and you have enabled
<arokux1> wingrime, thanks
hansg has quit [Quit: Leaving]
vicenteH has joined #linux-sunxi
<arokux1> are there any benchmarks where low end intel/amd cpus are compared against ARM ones
specing has quit [Ping timeout: 240 seconds]
n01 has quit [Ping timeout: 246 seconds]
rellla2 has joined #linux-sunxi
<WarheadsSE> not often validly
leowt has quit [Quit: leowt]
rellla2 has quit [Quit: Nettalk6 -]
<wingrime> mripard_: ping
<ganbold_> where to get u-boot for cubieboard2?
<wingrime> ganbold_: same as for cb1
leowt has joined #linux-sunxi
<ganbold_> strange, somehow SD that was working on cb1 is not working for cb2
<wingrime> ganbold_: you need build it for cb2
<wingrime> make cubieboard2_fel CROSS_COMPILE=arm-linux-gnueabi-
<wingrime> sorry
<wingrime> make cubieboard2 CROSS_COMPILE=arm-linux-gnueabi-
<wingrime> ganbold_: ^
<ganbold_> I mean u-boot
<wingrime> ganbold_: yes, u-booy
<wingrime> *uboot
<ganbold_> yeah that is what I thought and probably will do that tomorrow :)
<Turl> mripard_: yup was looking at it :) so >128 and soft cap it on <256
leowt has quit [Quit: leowt]
ganbold_ has quit [Remote host closed the connection]
dwilkins has quit [Ping timeout: 264 seconds]
dwilkins has joined #linux-sunxi
leowt has joined #linux-sunxi
blunden_ has joined #linux-sunxi
Soru has joined #linux-sunxi
blunden has quit [Ping timeout: 245 seconds]
<wingrime> mripard_: ping
ykchavan has joined #linux-sunxi
hramrach has quit [Remote host closed the connection]
<wingrime> mripard_!!!
hramrach has joined #linux-sunxi
specing has joined #linux-sunxi
<Turl> what's up wingrime?
<wingrime> I can't get probe messages
<wingrime> sunxi-dma: probe of 1c02000.dma failed with error -12
<wingrime> but every return have message, that I not see
<Turl> wingrime: can you paste the code?
<Turl> wingrime: you are missing {} on first if (!sdma)
<Turl> that's why you don't see any message
<Turl> if(!sdma) message() so message is not run
<Turl> and you return enomem (12) unconditionally
<wingrime> Turl: also mainline have support of AHB_CLK?
<Turl> wingrime: yes, and all the gates
<wingrime> Turl: how I can use it in dt?
rellla has quit [Ping timeout: 240 seconds]
<wingrime> I using only clocks = <&osc24M>;
<wingrime> So how configure it right way
<wingrime> Turl: oh, how I not noticed that barkets a missing , looks like I overplayed with python
<Turl> so you would use clocks = <&ahb0_gates 16>, I don't remember the exact node name but it's something like that
<Turl> wingrime: yeah, python has that effect at times :)
<Turl> wingrime: just checked, clocks = <&ahb_gates 16> for example if you need DMA gate on AHB
vrga has joined #linux-sunxi
<wingrime> 16 ?
<wingrime> DMA 6
<wingrime> on table
vrga has left #linux-sunxi [#linux-sunxi]
<Turl> err yeah, 6 :)
<Turl> wingrime: 16 is audio codec engine
<Turl> I'm quite distracted today
<wingrime> Turl, more one problem, mripard not defined clocks normaly
<wingrime> for sun7i
<Turl> wingrime: are you doing this on sun7i?
<wingrime> Turl: yes
<wingrime> but DMA IP same
<wingrime> only routes can be diffent slightly
<Turl> I think mripard_ sent a patch to add clock support
<Turl> wingrime: <&ahb1_gates something> I think
<wingrime> Turl: yes, but I hve add ahb1_gates too
<wingrime> and related
jacq has quit [Ping timeout: 240 seconds]
<Turl> wingrime: hm?
<wingrime> Turl: all clock tree missing from sun7i dts
<Turl> wingrime: sure you are using this branch?
<Turl> ah, sun7i, nevermind
<Turl> you have A20
<wingrime> no diffrent
<Turl> I'm too distracted today :)
<wingrime> I should add a20-clocks
<wingrime> merge branch
blunden_ is now known as blunden
<Turl> wingrime: yes, looks like it
Quarx has quit [Read error: Connection reset by peer]
<Turl> wingrime: it's two trivial patches
<Turl> mripard_ is missing the documentation for it though :) I suppose it is 6 also
<wingrime> Turl: yes, but now I have more one problem
<wingrime> Turl: I not make any commit yet
<Turl> wingrime: "git stash" :)
<wingrime> Turl: becose I not know any way rearrge patches for mainline
<Turl> "git stash" can save uncommited modifications, then you can apply any patches with am and "git stash pop" applies your changes again
<wingrime> Turl: no, for example I make many commits , so I want cut/ merge some for mainline patches
<wingrime> Turl: what better way create patchset
<Turl> wingrime: you need "git rebase" for that
<Turl> with --interactive
<wingrime> Turl: it usefull if I want join some or split?
<Turl> wingrime: yes, join is easy, you use "squash" or "fixup" option
<Turl> wingrime: split is harder, you need to stop and amend to remove pieces you don't like and make a new commit
<Turl> well, make two commits out of one that is :)
<Turl> wingrime: I would not worry about that for now though
<wingrime> Turl: for example I made some driver , with tons commit , fixes, Than I want spit last version for smal commits situable for mainline
<Turl> wingrime: you want to combine lots of commits into 1?
<Turl> you do rebase -i starthash then use fixup on everything
<wingrime> Turl: usualy I want last version (after checkpatch run) with some commits , splited for patchest
<Turl> wingrime: easy way would be to "uncommit" everything, then add by pieces and make good commits
<Turl> but more often you have already split and would like to move stuff around a bit, you can use rebase then
<wingrime> more offen I want hide some commits and join some to singe (some typo fixes)
<Turl> wingrime: for DMA driver I would not worry much, you would probably have 2-4 patches, one for driver and then one for dt (together or separate sun4/5/7i)
<Turl> wingrime: yes, for that you need to use rebase --interactive
rm has quit [Quit: ZNC -]
<Turl> wingrime: I use this on ~/.gitconfig
<Turl> wingrime: when I make typo I "git add" the typo
<Turl> then "git fixup hash" where hash is commit I want to fix
jacq has joined #linux-sunxi
<Turl> then "git ri origin/whatever" (the parent branch)
rm has joined #linux-sunxi
<wingrime> Turl: and I still no ide how test dma driver without anyclinets
<Turl> wingrime: I think there is a dma stress test thing in kernel
<wingrime> Turl: we not use mem->mem
<wingrime> Turl: usualy we use dev->mem or mem->dev
<Turl> wingrime: see "CONFIG_DMATEST"
<wingrime> Turl: and more important about cache and dma
<wingrime> Turl: you must know that cpu have cache , and dma can wirte to memory in avoid cache update
<wingrime> Turl: some times cache data can be outdated
<wingrime> Turl: so, difficult to cach problem
<wingrime> *catch
eebrah|away is now known as eebrah
<wingrime> Turl: maybe better use clock by name ?
atiti has joined #linux-sunxi
<Turl> wingrime: no, clock should be on DT
<wingrime> Turl: names also on DT
<Turl> yes, but names are for debug mostly
<Turl> wingrime: see clk/* inside debugfs
<wingrime> Turl: wait , need rebuild that I have now
<Turl> to see that you also need CLK_DEBUG or something like that enabled
FR^2 has quit [Quit: Connection reset by peer]
deasy has quit [Quit: Quitte]
<wingrime> Turl: remains only how to test it
<wingrime> 0.447266] sunxi-dma 1c02000.dma: initialized sunXi DMA driver
<Turl> wingrime: DMATEST not good?
<wingrime> Turl: onlt mem-mem test
jacq has quit [Ping timeout: 264 seconds]
<Turl> wingrime: well, better than not being able to test anything :)
<Turl> wingrime: adding DMA to emac can be a 2nd test
<wingrime> Turl: emac not enabled for sun7i
mcbrick has joined #linux-sunxi
jacq has joined #linux-sunxi
tzafrir has quit [Ping timeout: 264 seconds]
dl9pf has joined #linux-sunxi
focus_it has quit [Ping timeout: 246 seconds]
FunkyPenguin has quit [Ping timeout: 246 seconds]
Brodomir has quit [Ping timeout: 246 seconds]
eebrah is now known as eebrah|away
_BJFreeman has joined #linux-sunxi
Brod_ has joined #linux-sunxi
focus_well has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
FunkyPenguin has joined #linux-sunxi
Brod_ is now known as Brodomir
deasy has joined #linux-sunxi
<wingrime> Turl: funny I find undocumented DMA reg
<wingrime> only for sun7i it have name
<wingrime> but for sun[45]i
<wingrime> writel(1<<16, dma_base + 0x8);
<Turl> what does it do?
jemk has joined #linux-sunxi
<wingrime> auto gathing
<vi390> someone familar with script.bin screen resolution manipulation (A20 Cubieboard 3.4 Kernel) ; want to have 1024x768 working
<jemk> wingrime: it is documented in a10 manual
dl9pf has quit [Ping timeout: 240 seconds]
<wingrime> jemk: but not on a13
vincenzo has joined #linux-sunxi
<wingrime> jemk: you not right
<wingrime> I just open a10 manual
<wingrime> none there
<jemk> page 140-141
<wingrime> jemk: oh, but not in topic
<wingrime> jemk: I just looked at topic
<wingrime> jemk: thanks
deasy has quit [Quit: Quitte]
bsdfox_ has joined #linux-sunxi
bsdfox has quit [Ping timeout: 248 seconds]
leowt has quit [Ping timeout: 268 seconds]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
tzafrir has joined #linux-sunxi
jemk has quit [Ping timeout: 245 seconds]
<wingrime> hramrach: ping
<wingrime> hramrach: do you know what ACE doing
<Turl> wingrime: ACE = Audio Codec Engine I believe
<wingrime> Turl: driver like cedar
<wingrime> Turl: it use blob for mmap
<wingrime> Turl: where that blob?
<wingrime> mnemoc: ping
<Turl> wingrime: sure? I think it's alsa
<wingrime> Turl: defenetly noy
<Turl> wingrime: maybe it is part of cedar (CedarA)
<wingrime> Turl: Thats more realistic
<wingrime> Turl: becose it some times named as VA
tinti has quit [Quit: Leaving]
<wingrime> AE
<wingrime> not VA sorry
<wingrime> Audio Engine
BJfreeman has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-sunxi
deasy has joined #linux-sunxi
<wingrime> Trul: nice , sun4i pcm driver in good shape
<wingrime> Turl: if I clean it, possible mainline it
<wingrime> Turl: also,there is soc-dmaengine-pcm interface
<wingrime> but not in driver
<oliv3r> wingrime: yeah, allwinner manuals are ... tricky. some things are in one manual, others in the next manual :)
<wingrime> oliv3r: I made dma-engine driver skelet code
<oliv3r> i read
<oliv3r> very awesome
<oliv3r> not so sure how easy alsa driver to mainline is, it looked quite messy last time I saw it
<wingrime> oliv3r: But I have no idea how to test debug
<oliv3r> not as bad as disp though :)
<oliv3r> what about dma memcopy?
<oliv3r> does our hardware support it?
<wingrime> oliv3r: dma-engine have interface
<wingrime> oliv3r: you can see in backlog
<oliv3r> yeha i read, but then you made it sound like there was a kernel api for it
<oliv3r> and not the hardware anymore :)
<oliv3r> but you should add it to sun-3.4 so we can do some performance tests on it
<oliv3r> ssvb can test it for you really well ;)
<wingrime> oliv3r: why not hardware?
<wingrime> oliv3r: dma it self memory mover
<oliv3r> yeah you weren't clear is all
<oliv3r> so if we have hardware support for it, i wonder why allwinner didn't implement it in their driver
<oliv3r> should yield quite some performance? but maybe native is just as fast or faster then dma
<wingrime> oliv3r: it interact with cache
<wingrime> oliv3r: it can be slow with small blocks
<oliv3r> maybe that's why they didn't implement it?
<wingrime> oliv3r: also, do you know that DMA use same BUS and mem contoller
<oliv3r> MBUS yeah
<oliv3r> dramc obviously, and mbus
<wingrime> oliv3r: we need share it
<oliv3r> i documented the mbus registers on the ccm wiki page
<wingrime> oliv3r: running dma slow process memory access
<wingrime> *cpu memory access
<wingrime> oliv3r: do you have any idea how I can test dma
<oliv3r> not me; ssvb is memory benchmark mastert
<oliv3r> ssvb ^
<wingrime> oliv3r: also ACE driver
<wingrime> oliv3r: it use some blob
<oliv3r> i read
<oliv3r> i saw ace registers
<oliv3r> but they all 'appeared' to be unused
<oliv3r> but who knows what happens in cedarx
<ssvb> wingrime: if you have some dma optimizations for clear or copy pages operations, it is easy to construct a userland test
<oliv3r> but its deffinatly an audio something engine
<wingrime> oliv3r: it looks like CedarA
<wingrime> oliv3r: if it can mp3
<wingrime> oliv3r: will be nice
<oliv3r> yeah would be awesoem
<oliv3r> but we know nothing of it yet, we'd need to look at cedarA code (do we have that) to see if ti talks to those registers at all
<wingrime> oliv3r: it have second name AE - AudioEngine
<oliv3r> but VE uses PLL4, ACE uses PLL4, PLL5 or 24 MHz clock, so since it shares PLL4 it's not entirly unlikly
<wingrime> oliv3r: mistery without drivers and docs
<oliv3r> Audio Codec Engine
<oliv3r> well lets see if we have no code
<wingrime> oliv3r: blob
<oliv3r> do we have a blob for it?
<oliv3r> well there's a DRAM_ACE_GATE
<wingrime> oliv3r: we have driver for it drivers/media/audio
<wingrime> also strange PA driver
<oliv3r> i think they use it to encode audio mostly
<oliv3r> i think they use it with CSI to real time encode audio
<wingrime> oliv3r: it looks like A10 have cpu stong enought to do it
<wingrime> oliv3r: so thay not wirted any code
<oliv3r> wellr emember, these IP's where in older socs too
<wingrime> ssvb: probem , how test it in kernel
<oliv3r> and they may have been slower
<oliv3r> so if you want to record video with camera, you need to encode
<oliv3r> wingrime: why can't you test it in userspace?
<wingrime> oliv3r: dma_engine - kernel framework
<oliv3r> ace driver looks complete and blobless?
<oliv3r> reading code now
<wingrime> oliv3r: carefully look
<wingrime> oliv3r: it do basic ioctrl and MMAP
<oliv3r> ace uses SRAM
<wingrime> oliv3r: as cedar
<oliv3r> yep
<oliv3r> i do agree with you that this might be the audio engine
<oliv3r> we do know CedarA exists
<ssvb> wingrime: if the performance improvements are not visible from the userspace, then they fail to be useful ;)
<ssvb> wingrime: that's a "common sense"
<oliv3r> depends, if performance is similar, but cpu usage is reduces == win :)
<wingrime> oliv3r: it looks like soft decoder
<oliv3r> THat's the only reference i've found to cedarA for now
<oliv3r> (a quick google query)
<oliv3r> but cedarA deffinatly is audio accelerator
<oliv3r> shoudl be coold to have imo
<oliv3r> and i think it's then when you really wnat to use the AVS (audio Video Sync) timer
<wingrime> oliv3r: older soc defenetly used that
<wingrime> but a10 power enought to deal with audio
<oliv3r> yeha but if we can offload it, we should :)
<oliv3r> could save power for mobile users
<oliv3r> and yield more fluent user experience for set-top box users
<oliv3r> i first thought, that cedarX is the unification of cedarA and cedarV
<oliv3r> anyway, if the cedarA engine is simpler (and allows doing simple steps, fft, idct etc) we can re-use that for other hardware acceleration too ;)
<wingrime> oliv3r: catcha!
<wingrime> oliv3r: libac3_hw.a
<oliv3r> cedarA was used a lot in F19, F20, F21, F22 and F23
<oliv3r> sun3
<oliv3r> ohh nice
<wingrime> HW
<oliv3r> see, F23
<oliv3r> sun3i iirc
Offshore has quit [Ping timeout: 240 seconds]
<wingrime> only ac3
<oliv3r> libcedara_decoder.a
vincenzo has quit [Quit: Konversation terminated!]
<wingrime> frameworks/base/media/CedarX-Projects/audio_lib/AC3-V2/ac3_aw1620.c
<oliv3r> ohh
<wingrime> Open device ace_dev fail
<wingrime> ******************HW WORKING***************!
<wingrime> ACE_DEV_UNINS_ISR fail
<oliv3r> where did you find ac3_aw1620.c?
vi390 has quit [Ping timeout: 248 seconds]
<wingrime> strings in blob
<oliv3r> ohhh
<oliv3r> ok
<wingrime> JPGVEncInit, get MACC_REGS_BASE failed
<wingrime> we have hardware jpg encoder
<oliv3r> oh nice
<oliv3r> so we can use that to find more registers for jpeg
<oliv3r> jpeg encoder is very usefull to create thumbnails
<wingrime> oliv3r: it can be diffent engine
<oliv3r> and webcam feeds to mjpeg
<oliv3r> in that repo, :) see, cedar video was different
<wingrime> oliv3r: for a first look
<wingrime> oliv3r: we have ac3 and dts
<wingrime> oliv3r: hw decoding
<oliv3r> we should have 4 files
<oliv3r> strings * | grep ACE_DEV_GET_ADDR
<oliv3r> finds 4 entries, only 1 is from libac3_hw.a
<wingrime> ans possible jpeg enc and aac enc
<oliv3r> 1 is from dts_hw
<wingrime> oliv3r: witch files?
<oliv3r> nope, not jpeg enc
<oliv3r> so far, libac3_hw, libdts_hw
<oliv3r> i can't seem to find the rest :p
Soru has quit [Ping timeout: 264 seconds]
<oliv3r> ohh in the .so
<oliv3r> that has 2 references
<oliv3r> is strange, don't know what it is
<oliv3r> lots of audio stuff in it
<oliv3r> like all of them
<oliv3r> lib SoftWinnerAudio?
<oliv3r> i think, is what is for linux
<oliv3r> might not even be an android things?
<oliv3r> ar -t libac3_hw.a
<oliv3r> also interesting
<oliv3r> Decode_AC3AW1620obj.o
<wingrime> frameworks/base/media/CedarX-Projects/audio_lib/DTS/dts_aw1620.c
<wingrime> ssvb: ping
<oliv3r> ohh
<oliv3r> wingrime:
<oliv3r> wanna hear something interesting
<wingrime> ?
<oliv3r> ar -t libac3_hw.a | grep eac3dec
<oliv3r> ffmpeg is GPL licensed
<oliv3r> libac3_hw.a is a GPL violation
<oliv3r> lkcl_: ^
<oliv3r> maybe if we ask nicely, since it is really old unused dead code, we can get source code of cedarA :)
<oliv3r> lkcl_: ^ :p
<wingrime> libv: ?
<wingrime> libv: ^
<oliv3r> wingrime: libv isn't the gpl violation guy, lkcl is more or less
<lkcl_> oliv3r: ack. ta
<lkcl_> oliv3r: another one?? :)
<oliv3r> lkcl_: this is really old audio decoding/encoding stuff, they aren't even using it anymore i belive; it's from the sun3i days (though the kernel inteface is labeled sun4i)
<oliv3r> lkcl_: another one?
<oliv3r> violation?
<oliv3r> appearantly :p
<lkcl_> yeah, another gpl violation :)
<oliv3r> *flex*
<oliv3r> its interesting what you find when poking :)
<lkcl_> doesn't matter: if it helps put pressure on...
<lkcl_> yeah
<oliv3r> lkcl_: have you heard of the FSF, RMS and A10/A20 interest?
<oliv3r> Appearantly, RMS is super interested in A10/A20 SoC's due to their 'openness'
<lkcl_> oliv3r: dr stallman has been asking my advice, so yes.
deasy has quit [Quit: Quitte]
<lkcl_> and the price, and the reach.
<oliv3r> you aswell, paulk-collins is in the loop too
<lkcl_> ack
<oliv3r> so what is the status of the GPL violation pressure?
<lkcl_> still no answer yet.
<oliv3r> haven't seen updated u-boot sources for a20 that properly copyrights files, not seen a10, a31 sources officially
<lkcl_> they'll need a reminder.
<wingrime> lkcl_: like expected
<lkcl_> wingrime: there are ways and there are ways
<oliv3r> well you now have RMS sorta giving you weapons to put more pressure ont he kettle too
<oliv3r> lkcl_: also, cedarX reverse engineering is going steadily ahead
<lkcl_> i had to severely pressurise them to get the last lot - it was quite disruptive
<lkcl_> oliv3r: GOOD
<wingrime> lkcl_: good power
<wingrime> *god power
<oliv3r> still, for the more complex codecs, docs/code would be extremly helpfull
<wingrime> lkcl_: it blob with audio hw decoder
<oliv3r> lkcl_: it still strikes me, that with their support, they could be a gamechanger even now
<lkcl_> oliv3r: tell me about it.
<oliv3r> since they are slowly sinking again
<lkcl_> i pointed out to their technical director that the cedarx hardware, because it has faster access to the AHB/AXI bus than the main CPU, could be used as a co-processor for linux, to do basic things like memcpy *very* very quickly.
<oliv3r> lkcl_: their current socs are nice (a20) but don't perform super well (single threaded tasks a10 can sometimes even beat a20)
<lkcl_> oliv3r: well... they did go and set the benchmark for price-performance... and then muck it up by getting into bed with imgtec
<wingrime> lkcl_: imgtec?
<oliv3r> for powerVR on a31, yeh that's sad
<oliv3r> wingrime: powervr :p
<lkcl_> oliv3r: that doesn't surprise me... ok, it does a little - cortex a7's pipeline arrangement is different from cortex a8, and all the gcc optimisation went into cortex a8
<lkcl_> yeah powervr.
<oliv3r> lkcl_: preaching to the choire here, but if they wanna stay relevant, more GPLed support, get code for a40 (orwhatever is next) out earlier
<lkcl_> real major cock-up, that. you look at TI's pricing for e.g. the omap3525 vs the 3530, it was something like... a $5 price-jump.
<wingrime> oliv3r: but if you drop gpl side of question, powervr have normal opengl
<oliv3r> lkcl_: appearantly, a31 is considered a flop internally
<lkcl_> oliv3r: the only saving grace is that rock-chip are completely closed.
<lkcl_> otherwise allwinner would i think sadly be in deeper doodoo
<oliv3r> lkcl_: not really
<lkcl_> oliv3r: no?
<oliv3r> lkcl_: rock-chip has kernel code
<oliv3r> even some mainlined work done to it
<lkcl_> oliv3r: yes... but where's the bootloader?
<oliv3r> no bootloader
<lkcl_> where is the source code of the bootloader?
<oliv3r> and far not as far as we are
<oliv3r> so allwinner still has the advantage there
<lkcl_> is there an equivalent of fex?
<oliv3r> but they are not helping keeping it
<oliv3r> for rockchip? in mainline dts
<lkcl_> what's the equivalent of the fel-boot command that took 18 months to reverse-engineer?
<oliv3r> yeah we still have the advantage
<oliv3r> but without allwinners help, and their lack of anything; it's not good looking for them
<lkcl_> i'm not entirely asking rhetorical questions, i really want to know the answers :)
<oliv3r> there's no u-boot
<wingrime> lkcl_: there much problems with cedar thay mix realnetworks decoder too so I doubt thay open something
<wingrime> lkcl_: but audio part...
<lkcl_> oliv3r: the meeting with allwinner's technical director was very good. i can't say too much
<oliv3r> lkcl_: olimex and cubietech are planning rockchip boards
<lkcl_> wingrime: that's not our problem. if they can't comply they have to cease and desist distribution.
<oliv3r> you can say what you want, but olimex and cubietech are also important for allwinner
<wingrime> lkcl_: thay afraid lose advantage so much
<lkcl_> oliv3r: yes, i heard. i spoke to tom a couple weeks back.
<oliv3r> I've also found out that the full RK3066 Technical Reference Manual (1142 pages) has been leaked recently.
<oliv3r> obviously link got lost in copy/paste :)
<lkcl_> oliv3r: yes i saw that. i want the 3188
<oliv3r> but they have a full user manual
<oliv3r> so of course, rock-chip isn't as open (yet?)
<oliv3r> and they don't have as much (yet)
<lkcl_> yes, i have a copy. and the schematics etc. etc. reference design etc. etc. but it's just an equivalent to the A20. the 3188 is what's interesting.
<wingrime> lkcl_: we still not have a31 and a20 user manual ....
<oliv3r> if rock-chip would want to steal the sunxi community, they could do so quite easily, right now. support us with docs, support us with hardware :p
<oliv3r> quad-core a9
<oliv3r> should be 3188 kernel source
<lkcl_> wingrime: do you _really_ need them, that's the question
<wingrime> lkcl_: anyway we did a big step with cedar RE projct
<oliv3r> lkcl_: a31 usermanual isn't an issue
<lkcl_> wingrime: how's that going? got a link?
<oliv3r> a20, sorta, while its very similar to a10, there are minor subtle differences
<wingrime> lkcl_: we have jpeg decoder SoC
<wingrime> and mpeg12
<wingrime> Working
<oliv3r> PoC* :p
<lkcl_> wingrime: it's HIGHLY significant. cedarx in combination with lima would make the A10 and A20 literally the first commercially-viable mass-volume ARM SoCs in the world that are FSF-Endorseable
<oliv3r> yep
<oliv3r> :p
<oliv3r> anyway, bedtime :)
<oliv3r> nn
<oliv3r> get us docs/code soon :)
<lkcl_> wingrime: are you working publicly by pushing all code modifications and documentation up-to-the-minute into public repos?
<wingrime> lkcl_: I mostly wirte documents
<wingrime> lkcl_: jemk done code using my reference
<lkcl_> wingrime: ack. awesome. it's very important to not go "ohh mee, ohh myy, i must only publish this work when it's perfect".
Black_Horseman has joined #linux-sunxi
<lkcl_> "because someone might spot a mistake, or criticise me" or some other lame excuse
<lkcl_> those excuses deprive other people from being able to help you get this done faster.
<lkcl_> ... and we've already had two people drop off this project in slightly worrying ways...
<lkcl_> wingrime: awesome. let me take a look...
<lkcl_> oliv3r: night dude
<wingrime> lkcl_: test jemk code , it realy do decoding without blob
<lkcl_> wingrime: f*****g awesome.
<wingrime> lkcl_: not player, you need press "enter" to next frame
<lkcl_> it looks like it's really straightforward.
cajg has quit [Ping timeout: 246 seconds]
<lkcl_> that is a heeell of a lot of registers
<lkcl_> wingrime: this is great stuff.
<lkcl_> now we have to kick libv :)
<wingrime> lkcl_: it not all , have more regs , but it also about VC1 engine (old page)
<lkcl_> ack
<lkcl_> ok. enough for today. sleep
<lkcl_> thanks wingrime
<wingrime> also thanks nove - tracer and jemk for code
ykchavan has quit [Quit: Leaving]
bsdfox has joined #linux-sunxi
bsdfox_ has quit [Ping timeout: 245 seconds]
cajg has joined #linux-sunxi
vicenteH has quit [Ping timeout: 260 seconds]
deasy has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
<libv> lkcl_: don't i have enough on my plate already?
rings_IIV has joined #linux-sunxi
naobsd has quit [Quit: Page closed]