<hramrach>
hmm, gettimeofday() returns microseconds so it's kind of obvious why it ends up reading precision timer
n01 is now known as n01|work|away
<hramrach>
the exynos code caches the value and checks it did not cahnge much without latching but is not much faster and is not guaranteed to work on A10 as well :s
<hramrach>
better dma is cool
<RaYmAn>
a
<hramrach>
not sure I will be able to tell on any of my workloads but gives more potential :)
<hramrach>
so sun5i is again different and more bitrotten :s
<Turl>
RaYmAn: typing your password on irc is not a great idea
<hramrach>
maybe taking the sun4i config and doing sed s/SUN4I/SUN5I would work ;-)
<hramrach>
wtf CONFIG_SW_DEBUG_UART=1
<RaYmAn>
Turl: :D
<mnemoc>
hramrach: any difference is a bug
<mnemoc>
i mean, between 3.0 and 3.4
<mnemoc>
our defconfigs are intended to be consistent between 3.0 and 3.4, and also consistent across soc and usage (linux/android today, hopefully desktop linux, headless linux and android in short future)
<hramrach>
does sun5i not have ts, sound, keypad, ethernet?
<hramrach>
and gpio, vibrator?
<mnemoc>
patches welcomed ;-)
<mnemoc>
sun5i_defconfig is pretty useless anyway
<mnemoc>
only per-soc works
<mnemoc>
a10s and a13 are too different
<hramrach>
I tried to apply sun4i defconfig to sun5i
<mnemoc>
feature wise
<mnemoc>
both are sun5i, but the soc features (and so the defconfig) differ a lot
<hramrach>
but you can boot a10s kernel on a13, right?
<mnemoc>
yes, the heart of the soc is the same
<mnemoc>
and diffs can be handled at script.bin level
<hramrach>
so having two configs is optimization but not necessity
<mnemoc>
i would call it user friendliness more than optimization
<mnemoc>
but right, it's not a necessity
<hramrach>
if the purpose of the defconfig is to provide unified hwpacks that work on all devices with proper script.bin a single sun5i can work
<mnemoc>
allwinner uses a CONFIG to distinguish SoCs, if soc-detect decides to work, we can have a unified sun5i kernel bin
<mnemoc>
they have separated trees.... a1x for A13, and "elite" for A10s
<mnemoc>
and that means separated workarounds
<mnemoc>
but we need to integrate them all into a single source base anyway
<hramrach>
have same config for sun4i and sun5i now
<hramrach>
that some drivers are sun4i on sun5i is kind of weird
<mnemoc>
fully agree
<mnemoc>
those should be sunxi, not sunNi
<techn__>
mnemoc: SW_DEBUG_UART should be handled by soc then
<mnemoc>
techn__: good point
<hramrach>
what does it do?
<hramrach>
it's not set on sun4i
<mnemoc>
hramrach: earlyprintk
<techn__>
maybe it should be changed to EARLYPRINTK_USE_SD_CARD_UART=y/n
<mnemoc>
it's not only for the breakout
<hramrach>
is there a reasonable default value for sun5i?
<techn__>
it's true
<mnemoc>
it's just the debug uart of the board.
<mnemoc>
hramrach: in A13 it's uart1
<mnemoc>
I think DEBUG_UART is the normal name
<slapin_nb>
which minimal clock can be used by A10/A13 to drive SDRAM? if I do bad DDR3 routing on my board, will I be able to run it at low speeds, as I'm too lazy to calculate/correct tracks now?
torqu3e has quit [Quit: torqu3e]
n01 has joined #linux-sunxi
<hramrach>
what is the part unavailable on sun5i - only SATA?
<jinzo>
regarding to sun4i?
<jinzo>
in comparison to*
<hramrach>
yeah
<jinzo>
the RAM is limited to 512 and no HDMI afaik
<jinzo>
(in addition to SATA)
<hramrach>
there is hdmi on a10s?
<jinzo>
not sure about that one, I didn't look into it.
<jinzo>
looks like a13 and a10s have different capabilities indeed
<jinzo>
(but both being sun5i)
rellla has joined #linux-sunxi
<DagoRed>
Do the images for the MK802 work for the Mele A100? The hardware looks identical and I would like to run android 4.x on my A100.
<hramrach>
mele has more features
<hramrach>
so mk802 image would possibly work but make not full use of hardware
<hramrach>
if you replace kernel and script.bin then all features should work but might not be integrated in the android settings
<DagoRed>
Is there an android 4.x image available for the A100? I saw some boxes being sold on deal extreme with 4.1.
<hramrach>
probably
<hramrach>
if you don't want to build your own try to search the intewebs
<DagoRed>
Ok, so far I'm unsuccessful. My google fu must be weak.
<hramrach>
that they preaload it on something does not mean they publish it anywhere accessible (although they should)
<DagoRed>
I wouldn't mind building own in the future, I just want to get my box running. The box I have is from one of the Alarm guys doing dev work. I'll switch back to ALARM in the future but for now, trying to get some co-workers addicted to these little boxes.
rellla has quit [Remote host closed the connection]
<hramrach>
just try the mk802 image then and see what works
<DagoRed>
Ok.
<DagoRed>
Thank you.
<Turl>
mele had official images on their site, didn't they?
<DagoRed>
I think they did... I just can't find it right now.
<DagoRed>
I can't even find the official mele website, unless it's all in chineese.
<hramrach>
wingrime: the sun5i defconfig builds ;-)
<hramrach>
use google translate
<hramrach>
or learn what picture Chinese use for 'download'
<hramrach>
but yes, I would expect they have English site too
<ssvb>
and instead of kde with kwin_gles compositing manager, it's probably easier to first try something simple like glmark2-es2
<ssvb>
and once everything is working properly, kwin_gles should be also fine
eebrah has quit [Ping timeout: 248 seconds]
<ssvb>
wingrime: does 3d acceleration work fine now?
<wingrime>
kde running but without kdm
<wingrime>
kdm crashed with:libGL.so.1 not found
<ssvb>
as I said, maybe try something simple like XFCE with simple GLES applications?
<ssvb>
it should be way easier to debug
eebrah has joined #linux-sunxi
<wingrime>
kwin: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<wingrime>
kwin: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<ssvb>
for mali acceleration it should be using kwin_gles, not kwin
<ssvb>
with anything depending on libGL.so you can only get slow software rendering for 3D graphics
<wingrime>
I wonder that so hard to translate eachother
<wingrime>
kwin(2725): Required extension GL_OES_EGL_image not found, disabling compositing
<n01>
guys, don't we have a defconfig for the DT branch?
<ssvb>
wingrime: somebody has decided that embedded devices need simplified API and simplified hardware for 3D graphics, so you can't easily run 'desktop' 3D applications without major porting efforts
<n01>
mripard_: to boot the kernel with dt are you using sunxi-u-boot?
<mripard_>
I'm using appended dtb
<mripard_>
so I just load the kernel image as usual
<mripard_>
with the dtb that has been previously appended to it
<ssvb>
wingrime: still KDE also has kwin_gles compositing window manager for desktop effects, and it can successfully use OpenGL ES acceleration provided by the mali blob driver (KDE folks have done the needed work)
<wingrime>
ssvb: that message was from kde_gles
<wingrime>
kwin(2725): Required extension GL_OES_EGL_image not found, disabling compositing
<wingrime>
kwin_gles I mean
<ssvb>
wingrime: can you pastebin full output from kwin_gles?
<ssvb>
wingrime: it looks like your drivers are still messed up
<jinzo>
I wonder for who mike valk works... I would vager my bet on rockchip
<hramrach>
I wonder if nohighmem kernel can handle the 800 something M like on x86 or we need highmem for 1G boards
<hramrach>
but definitely not needed on sun5i if it has 512M max
shineworld has joined #linux-sunxi
<jinzo>
hramrach, but then again a10s is sun5i and max is 2GB supposedly.
<hramrach>
well, sun5i has half the memory controller of sun4i
<mnemoc>
hramrach: "nuclear" is a13's android
<hramrach>
2G is max on a10 supposedly but no board has
<hramrach>
nuclear without sun5i prefix?
<mnemoc>
hramrach: a10s' is "elite"
<mnemoc>
hramrach: a13_nuclear_defconfig
<jinzo>
hramrach, indeed.
<jinzo>
I think olimex reported major problems with that stuff.
<hramrach>
can't the configs have somewhat consistent names /o\
<mnemoc>
2GB on A10. but afaik they didn't try on A10S
<mnemoc>
hramrach: patches welcomed :)
<hramrach>
I think olimex reported major problems with designing board not based on the AW reference design
<jinzo>
mnemoc, still not released/haven't heard anything. The A20 news are good tho
<jinzo>
couldn't catch Tsvetan to ask him what's the price range
<hramrach>
trying 2G on that board was just adding more unknowns but they did not report even getting the 1G board working
<ssvb>
wingrime: sorry for being annoying and repeating, but you are really trying to test mali drivers in the most difficult and time consuming way
<ssvb>
wingrime: but if you are enjoying the process, then it's probably fine :)
<hramrach>
picking linaro was possibly bad idea
<hramrach>
I had no drivers on Debian so just built everything from git. No problem there.
<wingrime>
ssvb: I must find why debian hung on suspend when x11 run (framebuffer driver)
<shineworld>
any rumors about cubieboard with A20 ?
<shineworld>
I've see A20 name in some line above
<n01>
mripard_: got it, I have finished the new watchdog driver and want to give it a try (using dt)
<mnemoc>
shineworld: there are working on a A31 board. A20 will probably happen once AW start selling them
<mripard_>
n01: cool
<mripard_>
n01: tell me if you need anything
<n01>
:) thank you
<shineworld>
A31 ? .... quad processor ? interesting ... some info about card size ?
<mnemoc>
he mentioned to aim at intel's nuc formfactor
<mnemoc>
with all pins in headers this time
<n01>
and a brand new name :D
<hramrach>
but with 31 :(
<hramrach>
A31
<mnemoc>
i've been begging him for a A20 "nuc"ish device too
<shineworld>
A31 should be very close to iMX6 but with better community than frescale
<ssvb>
hramrach: mali still does not have much practical use, but quad NEON should be good (unless they stripped it too much in Cortex-A7) :)
<ssvb>
hramrach: though the loss of SATA is a pity
<shineworld>
I don't use SATA but more math and cpu power is welcome
<DagoRed>
I have a iMX6Q board... I should start using it again.
* DagoRed
doesn't know what to do with it at times.
<shineworld>
I a Wandboard dual lite ... only 2 cores
<shineworld>
but I would like to try also 4 core ... but how I said the freescale community and support are terrible
<shineworld>
at moment
<shineworld>
*I have
<techn__>
shineworld: how come?
jorgegeorge has joined #linux-sunxi
<DagoRed>
I know the kernel 3.0. Kinda pathetic.
<hramrach>
ssvb: 2x lame core or 4x lame core is not much difference
<shineworld>
I'm working with freescale chips by many years ...
<shineworld>
never arm ...
<shineworld>
other chips
<ssvb>
hramrach: but 4 cores is still 2x less lame than only 2 cores :)
<jorgegeorge>
I'm trying to have g_ether eem working on the latest 3.4 without success, are there some tricks needed on the fex file or some experimental branch to be used ?
<hramrach>
until somebody decodes full hd in software on them
<hramrach>
they make maybe slightly faster kernel compiles
<hramrach>
so practically useless
<ssvb>
hramrach: they might be quite useful for taking care of 2D graphics (for example use an extra Cortex-A7 core instead of G2D)
<ssvb>
hramrach: in either way, your "primary" CPU gets free for other tasks :)
<jorgegeorge>
could somebody give me a hint on this "ERROR: could not insert 'g_file_storage': No such device" my problem is on 3.4 (on 3.0 works)
<n01>
uhm, I'm not sure
<jorgegeorge>
I'reading mailing list/ irc logs / google group without any point about it
<mripard_>
n01: anyway, both should work fine
<mripard_>
but you can use devm_request_and_ioremap
<n01>
sure but before I should get the resources
<mripard_>
ouch, yes, sorry. I'm getting tired
<mripard_>
I meant of_iomap
<n01>
:) yep ... anyway really useful review!
<hramrach>
jorgegeorge: you are using obsolete gadget
<mripard_>
oliv3r: and I meant of_iomap for you as well, instead of devm_request_and_ioremap
<n01>
actually a lot of device drivers still use devm_request_and_ioremap with dt ... I need to investigate a bit on this
<hramrach>
not that other gadgets work flawlessly but it's not realy an arror that this particular one is broken ;-)
<mripard_>
n01: it's really a matter of taste
<mripard_>
also, devm_request_and_ioremap will work with and without dt
<oliv3r>
how can it be 'taste' :p shouldn't there be one proper way of doing it? :)
<n01>
yeah, sometimes redundancy is confusing
<mripard_>
of_iomap will work only for dts
<hramrach>
timtowtdi
<mripard_>
oliv3r: it's really a matter of different interfaces to the same backend
<hramrach>
if there is a 'blessed' way maybe look kernel docs to find out
<oliv3r>
mripard_: yeah but if there's several, shouldn't some be pruned?
<mripard_>
I tend to use of_iomap because it's just less code :)
<oliv3r>
:p
<mripard_>
I'm kind of lazy :)
<hramrach>
sometimes you have shorthand interface and interface that includes gory details
<oliv3r>
true
<hramrach>
which are both useful
<oliv3r>
yeah
<oliv3r>
to bad there's no prber howto's or documetnation
<oliv3r>
you just have to 'guess'
<jorgegeorge>
I tried both "git checkout stage/sunxi-3.4" and "git checkout sunxi-3.4" where can I find the up-to-date gadget ?
<hramrach>
jorgegeorge: the gadget type is obsolete
<hramrach>
when yo uselect it in menuconfig you see (DEPRECATED) next to the option
paulk-desktop has quit [Quit: Ex-Chat]
<jorgegeorge>
I see. I ca switch for it to "Mass Storage Gadget", anyway I have the same error for other gadgets: "ERROR: could not insert 'g_ether': No such device"
<hramrach>
that's odd
<hramrach>
g_ether works for me
<hramrach>
at least on stage/sunxi-3.4
<oliv3r>
mripard_: not happy with the sun4i vs sunxi thing :p
<oliv3r>
mripard_: i haven't checked sun3i, but i think some of our stuff may be sun3i compatible (and first appeard)
<oliv3r>
so should I thus name it sun3i?
<hramrach>
it should be sunxi for common driver and sunNi for specific driver
<oliv3r>
hramrach: mripard_ says in 3.8+ it's being changed to "We try to remove the sunxi stuff from the compatible strings. The
<hramrach>
some drivers don't follow and sun5i uses numerous sun4i drivers
<oliv3r>
general usage is to use the earliest SoC this IP has been found in, so
<oliv3r>
it should be allwinner,sun4i-sid
<jorgegeorge>
on menuconfig on 3.0 I was using "SUN4I USB2.0 Manage/USB0 Controller support (device only support)" now on 3.4 I only see "Host only support", should I disable it ?
<hramrach>
jorgegeorge: you should select OTG or device only
<hramrach>
but might not be available if the controller is not configured in gadget config
<mripard_>
oliv3r: it's about compatibility, nothing more
<mripard_>
the question you have to ask to yourself is "is the security id stuff in the A13 compatible with the one in the A10"
<mripard_>
if the answer is yes, you should have the same compatible
<mripard_>
but it's only about the compatible
<mripard_>
not the name of the driver
<oliv3r>
mripard_: so only for the dt stuff then?
<oliv3r>
mripard_: that does make complete sense to me
<oliv3r>
i'll reply to the e-mail with more questions on your replies :p (lots to learn still)
<oliv3r>
mripard_: also, i assume we'll 'ignore' sun3i, right?
<mripard_>
yes
<jorgegeorge>
hramrach: do you mean in "USB Gadget Support/USB Peripheral Controller" ?
<mripard_>
and yes, the sun4i-sid comment is only about the content of the compatible string in the dt (and in the device_table array, of course), nothing more
<mripard_>
but all the dt bindings are supposed to be an interface, like the syscalls and so on
<mripard_>
so we can't modify it afterwards
shineworld has quit [Remote host closed the connection]
<hramrach>
jorgegeorge: yes that. you need to set it to built-in and then pick sun4i/sun5i
<oliv3r>
mripard_: i then completly agree
<oliv3r>
i thought we where naming drivers; but just dt, yeah i get that
<mripard_>
no the driver is fine, since it's for the moment the driver is usable on all the sunxi stuff, it definitely makes sense to call it sunxi :)
<hramrach>
that branch has the configs modified so that the OTG mode gets selected by default
<oliv3r>
mripard_: you replied to the actual patch! not to my own reply to the patch (that I cced you on) that had tons of questions :) oh well
<hramrach>
so you make sun4i_defconfig or sun5i_defconfig and build the kernel
<mripard_>
oliv3r: oh, yes
<mripard_>
sorry, I forgot this patch
<mripard_>
s/patch/mail/
<oliv3r>
mripard_: it's ok, you gave valueable info allready
<hramrach>
the problem is with ' can't modify it afterwards'
<jorgegeorge>
hramrach: thanks I found the reason, I had is selected as module and I was not gettin the SUN4i option, checking it as kernel I can select the SUN4i controller
<hramrach>
because sun3i is there but we have no testing of that platform
<hramrach>
and most drivers would be same but not all presumably
<mripard_>
oliv3r: if you have any more questions, don't hesitate to reply
<mripard_>
hramrach: then we can always add, say a sun3i-sid compatible string
<mripard_>
it's read-only if you prefer, you can add new stuff, but once it's there, you can't modify or remove it
<oliv3r>
yes, yes you can!
<oliv3r>
:p
<hramrach>
mripard_: how does DT handle when you assign the 'earliest SoC the IP has been found in' but then somebody brings an older SoC and the stuff is htere too?
<oliv3r>
hramrach: you lie :po
<oliv3r>
you say in sun3i.dts -> compatible=sun4i
<mripard_>
like I said, you add a new compatible string, which would be sun3i-*, and keep the sun4i one
<mripard_>
or we can lie, like oliv3r suggested :)
<mripard_>
but anyway, it's definitely doable
<mripard_>
we have several solutions, so we'll see when that case will happen
wingrime has quit [Ping timeout: 260 seconds]
<oliv3r>
but unlikly to see sun3i go mainline imo
<hramrach>
not as things are now
<hramrach>
with 0 people known using it
<hramrach>
but most drivers could be likely used from sun4i
<hramrach>
so if somebody came at the time sun4i is mainline and wanted to do sun3i too it would not be too difficult
<mripard_>
hramrach: that's what I think as well, and that's why I don't worry too much about it
n01 has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
eebrah_ has joined #linux-sunxi
eebrah_ has quit [Ping timeout: 245 seconds]
_whitelogger has joined #linux-sunxi
simosx has quit [Quit: Αποχώρησε]
torqu3e has quit [Quit: torqu3e]
<jorgegeorge>
Hramrach: do you have .config working with g_ether to share ? I have non errors in any place now, but also to talking on the USB...
<jorgegeorge>
I mean no erros in any place, but no talking on usb
<jorgegeorge>
SOLVED ! I has just a remaining problem of fex in script.bin