<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 :)
<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: 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)
<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>
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
<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?
<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
<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 github.com/linux-sunxi, 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)
<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
<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
<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!]
<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_>
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
<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