<oliv3r>
if only it didn't have that very stupid power VR
hurtigbuffer has joined #linux-sunxi
<oliv3r>
hno: yeah it's no9t a little different, it's a completly 'new design'
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<rm>
no worries, it will work just fine as a server :D
<oliv3r>
sure, but it's not sending a clear single
<oliv3r>
'we buy powerVR anyway'
<oliv3r>
'here powerVR, have some money for this shit GPU, even though I don't even use it'
hurtigbuffer is now known as jelly-home
rellla has joined #linux-sunxi
Soru has quit [Ping timeout: 246 seconds]
Soru has joined #linux-sunxi
jukivili has quit [Remote host closed the connection]
rellla has quit [Remote host closed the connection]
n01 has joined #linux-sunxi
rellla has joined #linux-sunxi
jukivili has joined #linux-sunxi
arete74 has joined #linux-sunxi
<mripard_>
oliv3r: honestly, while I understand your stand on the PowerVR, I really don't see any difference regarding the openness of the company that backs both GPU
<oliv3r>
mripard_: so you haven't had time to look at greg's comment? :)
eebrah is now known as eebrah|away
n01 has joined #linux-sunxi
eebrah|away is now known as eebrah
Soru has quit [Ping timeout: 248 seconds]
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
<oliv3r>
hno: those two patches i've sent you, finish the a20 work before merging it back imo, unless sun5i doesn't work with it. Sun7i works just fine and sun4i works equally aswell :)
<oliv3r>
hno: if you take all mails from me from sunxi and delete those that I replied to to be ignored; you should have all that needs merging
<oliv3r>
2 for a20 branch, a few for sunxi-current
<mripard_>
oliv3r: yes, something like 5-6 hourss
egbert_ is now known as egbert
jinzo has joined #linux-sunxi
<oliv3r>
mripard_: just to boot; lol that's really slow :)
<oliv3r>
0.5 MHz
<mripard_>
no kidding :)
<mripard_>
oliv3r: and for greg's comment, have you considered just asking him what he meant ? :)
<oliv3r>
rellla: cna you test rudi's patch?
<oliv3r>
mripard_: of course, many times, but .. it's greg, one does not just ask greg!
<oliv3r>
i'll reply now then :)
<rellla>
oliv3r: not atm, but soon surely.
<oliv3r>
rellla: the one that fixes some offset thing
<oliv3r>
would be great to merge it asap if it fixes things
<rellla>
how can crashing cedarx be reproduced based on this issue?
<oliv3r>
rellla: overflow :D
<oliv3r>
i'm not very sure this happens much at all
<mripard_>
oliv3r: I'll do it if you want.
<mripard_>
I'm interested in how can it race anyway
<oliv3r>
mripard_: nah, i'll mail him, i'll have to get over my fear at some point ;)
<oliv3r>
mripard_: okay then :)
<oliv3r>
my only guess is, that he overlooked the 'binary' bit
<oliv3r>
and then i agree, using the default attributes is smarter
<oliv3r>
mripard_: thanks, atleast I don't look even more dumber then usual ;)
<oliv3r>
mripard_: also, i really really intend to start a31 dram init looking into now
<oliv3r>
mripard_: spent all weekend on a20 stuff and getting sun4i to boot from the same codebase
<oliv3r>
so all ready to look at sun6i now
jukivili has quit [Ping timeout: 255 seconds]
<hramrach_>
mripard_: last time I looked tegra opensource drivers were a mess and nVidia only comitted to making a framebuffer driver - like vesa without the bios
<ssvb>
oliv3r: have you introduced any changes to sun4i dram code or was that just assigning names to magic constants?
<oliv3r>
ssvb: sun4i dram code remains the same, only names
<oliv3r>
ssvb: sun7i dram code has been changed
<oliv3r>
so it's time to add sun6i code if possible and to start merging stuff
<oliv3r>
e.g. some order changes if they work; tons of cleanup, it's kind of messy
<oliv3r>
and figuring out if certain changes really are needed or not
rz2k has joined #linux-sunxi
<ssvb>
oliv3r: good, so the resulting dram.o file remains the same before/after patch for sun4i?
hramrach__ has joined #linux-sunxi
<oliv3r>
it should
<oliv3r>
if you use CONFIG_SUN4I it should be identical
<ssvb>
somebody needs to verify this, just in case :)
<oliv3r>
i did split the patch in
<oliv3r>
so that it's very easily verifiyable
hramrach_ has quit [Ping timeout: 240 seconds]
<oliv3r>
ssvb: feel free to comment on the patch series :)
[hawk] has joined #linux-sunxi
vincenzo has quit [Ping timeout: 248 seconds]
<libv>
mripard_: what, kusma now works for nvidia?
<libv>
he never told me :(
<mripard_>
libv: I was thinking about Thierry Redding
<libv>
mripard_: erik faye-lund started the work several months before
jukivili has joined #linux-sunxi
<libv>
after i got him to steer clear of pvr (like i did with the etnaviv guy)
<wingrime>
oliv3r: what do you think about jpg
<wingrime>
oliv3r: where it can be used
<libv>
kusma, as a former falanx engineer, spent his first 7-8 months in the lima channel telling cwabbot and flatmush to "look at this shader, it might be interesting"
<oliv3r>
in android? tons of places
<libv>
and then decided somewhere in the summer to go do it himself
<oliv3r>
wingrime: ideally, we'd want to patch libjpeg(-turbo) to use it and see if there's a performance gain
<wingrime>
oliv3r: it will be like full repace
<oliv3r>
wingrime: think of all those thumbnail generation tools, if that can be sped up; *win*
<wingrime>
oliv3r: becode cedar take care whole decoding
<wingrime>
oliv3r: I mean, cedar do wholl jpeg after proper config
<wingrime>
oliv3r: PoC are workable
bfree has quit [Quit: Konversation terminated!]
jemk has joined #linux-sunxi
<oliv3r>
wingrime: partial, but yeah, thing is, libjpeg is 'standard' so by replacing libjpeg-sunxi.so; every product on the planet can use an accelerated libjpeg :)
<oliv3r>
which is a win :)
<oliv3r>
nothing needed to port etc
<oliv3r>
libv: mripard_ needs some convincing that powerVR is more evil then any of the others ;)
<wingrime>
oliv3r: libjpeg have no simple API. not so simple as I remeber
<ssvb>
jemk, oliv3r: probably one page with a short summary for all cedar registers is fine, individual sub-engines may get their own pages with more details
tinti has quit [Quit: Leaving]
<ssvb>
I think the PDF documentation for various hardware is typically structured this way
<oliv3r>
ssvb: i just went with how I did all the other pages so far
<oliv3r>
once we have more info, we can split it up more
<oliv3r>
splitting is easy
<oliv3r>
writing the shit, is a pain :)
<ssvb>
sure :)
<oliv3r>
so feel free to split it as you see fit ;)
hglm has joined #linux-sunxi
<hglm>
ssvb: I have been looking at the kernel ARM memcpy functions recently...they are slightly out-of-date to put it mildly
<oliv3r>
isn't the arm kernel we use slightly out-of-date?
<oliv3r>
i mean, we are on 3.0 and 3.4
<hglm>
Yeah but upstream there isn't much improvement I believe
<hglm>
Some critical functions are still optimized for a 15 year old ARM chip.
<ssvb>
hglm: the optimal implementations of memcpy tend to be SoC specific (not even ARM core specific)
<ssvb>
hglm: it's hard to make something that is universally good everywhere
<hglm>
ssvb: I understand, but there is a lot of room for improvement.
<hglm>
For example on the RPi I saw an almost doubling of performance with a few tweaks to memcpy/copy_page, on allwinner memcpy also can go somewhat faster
<ssvb>
hglm: to put it mildly, the RPi hardware has a lot of weird quirks, so it is not a very good example
<hglm>
And then there is the bug in memset that be the reason newer versions of gcc can't be used to compile ARM kernels like linux-sunxi.
<hglm>
ssvb: Yeah I know, the RPi is odd-ball probably because it was never designed to have a general purpose CPU
<ssvb>
hglm: to add an insult to injury, RPi was a bit misconfigured originally to have write-allocate enabled for L2 cache (which is not a very good idea because it has different cache line size than ARM core)
<ssvb>
yes, now L2 write-allocate is disabled by default on Raspberry Pi, but you still can enable it to see how it behaves
<hglm>
Regarding the kernel memset bug, that could be worth investigation to see whether it is the reason gcc 4.8+ can't be used to compile linux-sunxi and other ARM kernels. I already fixed it but haven't tried new gcc yet.
<ssvb>
in any case, you can already see that any memset implementation performs the same on Cortex-A8 and anything newer (unless you write one byte at a time and CPU itself becomes a bottleneck)
tinti has joined #linux-sunxi
<hglm>
Yeah memset easily reaches the maximum unless the code is really dumb.
<ssvb>
for memcpy implementations, newer ARM cores also show more consistent performance without the need for special tricks in order not to hit some severe bottleneck
<ssvb>
but still you might get some 10% or 20% performance extra
<hglm>
ssvb: yeah, the newer ARM cores do automatic predictive prefetching I think.
<ssvb>
still Cortex-A7 seems to be an odd ball :-/
<hglm>
Yeah that's what I see, you can get 15-20% over standard (glibc for example) memcpy on Cortex.
<hglm>
Is Cortex-A7 the dual core used in the A20 and Rockip 3166?
<ssvb>
yes, it's the dual core from A20
<hglm>
I saw some of your banwidth numbers and at least it doesn't seem to be crippled (some improvement with smae DRAM bus and speed as the A10)
<ssvb>
unfortunately I see some problems in pixman microbenchmarks, the difference from memcpy there is that you may want to read from multiple source buffers at a time and write to a different destination
wingrime has joined #linux-sunxi
<wingrime>
oliv3r: we not have reverse buffer we have "reconstruct"
<oliv3r>
what is 'reconstruct' :)
<oliv3r>
it just sounded like a typo, fwd and reconvstruct
<oliv3r>
but please do rename if you find an error :)
<hglm>
ssvb: I understand, when the source stride is bigger than the width of the image, the A7 will constantly prefetch data that isn't used...I guess preload instructions won't help to counter that.
<wingrime>
oliv3r: bad idea take all regs to one table
<wingrime>
oliv3r: we have general regs + engine regs
<oliv3r>
wingrime: that is the register LIST
<oliv3r>
the register table is below :p
<oliv3r>
think of it as an index
<ssvb>
hglm: the preload instructions are necessary to get good performance on A7 as the automatic prefetcher seems to be of limited use
<ssvb>
hglm: the effectively available memory bandwidth in A20 seems to be much worse than for A10, maybe some special tricks are needed, but I have not figured it out yet
<ssvb>
hglm: the cache in Cortex-A7 is write-allocate by default, but can switch to read-allocate mode automatically
<hglm>
ssvb: I guess the L2 cache is the main reason (different method due to multiple cores) for the reduction in peak memory bandwidth.
<ssvb>
hglm: yes, A20 needs to use SCU, which adds a bit to the latency and makes memory subsystem somewhat more complex
<hglm>
ssvb: Still, the dual cores should still make it a lot faster in practical use compared to A10.
<ssvb>
sure
<hglm>
It helps the X server too (the X server process gets run in parallel and becomes sort of CPU-based accelerator).
<hglm>
Does anyone know what the current situation is with respect to the gcc version (linaro for example) used to compile linux-sunxi? gcc-4.8+ doesn't work?
<hglm>
What is the reason gcc 4.8+ cannot be used? Is there a known problem?
<ssvb>
I believe it is some not quite C standard conforming code in the older kernel code, which gets botched by more aggressive optimizations in gcc 4.8
<ssvb>
I may try to fish out some links from the arm-kernel mailing list
<hglm>
I was think it might have to do with the ARM memset bug which is related to C-compiler optimizations...
<hglm>
The problem is that the assembler memset function has a C prototype returning a void * (not void) that gcc expects to hold the destination address of the memset call following memset specifications.
<hglm>
But the assembler memset function doesn't return any sane value.
jemk has quit [Ping timeout: 276 seconds]
<hramrach__>
I am using gcc 4.7 from emdebian and it works
<hramrach__>
ideally latest gcc should work too but I guess it's OK to use old gcc for old kernel and bother about incompatibility only if such code slips into 3.11
hansg has quit [Remote host closed the connection]
<hramrach__>
hmm, linaro seems to be pushing forward gcc versions
<hglm>
I will try experiment with compiling the kernel with a newer gcc version -- I have already fixed the memset bug so maybe it will work.
<hramrach__>
hmm, the latter one is supposedly fixed.
<hramrach__>
but latter comments speak about kernel code breakage
<hramrach__>
seems we should not worry about this until upstream kernel maintainers make the mainline kernel work with gcc 4.8
<hglm>
I am now trying to compile the kernel with gcc-4.8, there seems to be a problem with drivers/gpu/mali...but running make again fixes it.
<ssvb>
hglm: I think the mali module might be not parallel build friendly and may trigger spurious failures (don't remember if I have seen this information somewhere or it was just my guess)
<ssvb>
I never tried to really investigate this issue though
<hglm>
hglm: Yeah it seems to be some kind of dependency issue.
<hglm>
ssvb: BTW, I used your OProfile patch wih good results on the RPi platform. I do get a "sample buffer overflow" warning now and then.
<ssvb>
hglm: oprofile is out of fashion nowadays :) everyone is supposed to use perf
<hglm>
ssvb: Well perf only supports hardware performance counters, and OProfile does also support hardware performance counters. But the ARM hardware apparently doesn't.
<ssvb>
hglm: adding "-e cpu-clock" option will make perf use the generic timer
mnemoc has joined #linux-sunxi
<ssvb>
hi mnemoc!
<hglm>
ssvb: Ah, didn't know that about perf.
<bfree>
wb mnemoc, hope you're doing well! take care of yourself
<hglm>
The zImage produced by gcc 4.8 is 5K smaller than gcc 4.7, proof of better optimization?
<ssvb>
it does not mean anything
<hglm>
I guess there are a lot of variables in the toolchain etc, and a trivial alignment change would make a big difference, but still zImage is supposed to be pure code.
BJfreeman has quit [Ping timeout: 252 seconds]
<ssvb>
it may be just using less aggressive inlining, which could be improving performance or it could be degrading performance
<ssvb>
but in any case, my limited tests show that gcc 4.8 is a generally good release for ARM, which brings some nice speedups
<ssvb>
(at least for userland code)
<hglm>
ssvb: That's good, when I looked at it a few versions back it seemed gcc was broken in performing some trivial loop optimizations etc.
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
tzafrir has joined #linux-sunxi
<Turl>
mnemoc: hey! welcome back! :)
jemk has quit [Ping timeout: 246 seconds]
rellla has quit [Ping timeout: 248 seconds]
Superpelican_ has joined #linux-sunxi
<Superpelican_>
Hello I have a rebranded Point of View Protab 2 XXL tablet and I'm trying to boot Mer on it
<Superpelican_>
As it's a ICS tablet it loads Android with U-Boot
<Superpelican_>
So I thought I could let the U-Boot on the NAND also load Mer (or every GNU/Linux distribution)
<Superpelican_>
Without building Uboot-sunxi and putting uboot on my sd card
<Superpelican_>
However the tablet still boots Android instead of my kernel
<Superpelican_>
I've got the linux.ini file that came with the tablet and it cleary says that it boots u-boot.bin, not an bImage
<oliv3r>
mnemoc: Hey mnemoc !! welcome!
<Superpelican_>
So could someone explain to me whether or not I should add U-Boot to my bootable SD card?
<oliv3r>
mnemoc: feeling a little better yet?
<mripard_>
mnemoc: welcome back, I hope that you're feeling better :)
<oliv3r>
mripard_: see, i'm telling you, he overlooked the binary bit
<mripard_>
oliv3r: I don't know, I'm digging in the code right now to figure out how it's actually registered, to get if we can pass the flag that makes it binary anyway
<hramrach__>
Superpelican_: technically you can do without making abootable SD card but it's easier that way
<Superpelican_>
hramrach__:I've checked uboot-sunxi on Github but it doesn't seem to support the Protab 2 XXL
<oliv3r>
mripard_: i did a little poking back then, (mostly because I had to figure out how to write it) but didn't find much
<Superpelican_>
hramrach__:Only the Protab 2 IPS
<oliv3r>
Superpelican_: i higly higly doubt that
<oliv3r>
u-boot is very easy to suport
<hramrach__>
Superpelican_: just buil u-boot for random similar tablet
<hramrach__>
and that does not matter anyway. u-boot reads that from script.bin
<oliv3r>
e.g. protab XXL is 512 MiB; protab 2 is 1024 MiB
<Superpelican_>
but you just said that the script.bin is broken
<oliv3r>
hramrach__: u-boot reads nothing from script.bin
<hramrach__>
how does it set up memory then?
<oliv3r>
Superpelican_: ok you may have to add a section for the protab2
<Superpelican_>
xxl
<oliv3r>
xxl :p
<Superpelican_>
So I should create a new dram_pov_protab2xxl.c ?
<Superpelican_>
Is that all that is device specific in U-Boot?
<oliv3r>
copy dram_pov_protab2.c to dram_pov_protab_xxl.c
<oliv3r>
change 'size' to yours and density
<Superpelican_>
oliv3r:And aside from a new dram .c file I don't have to add anything device specific?
<hramrach__>
there is source for each memory config? /o\
<oliv3r>
edit Makefile, add it
<oliv3r>
and edit boards.cfg
<oliv3r>
add it there too
<oliv3r>
for u-boot; that is EVERYthing
<oliv3r>
:)
jemk has joined #linux-sunxi
<oliv3r>
u-boot only needs dram setup
<Turl>
hramrach__: yeah, generated with fexc from script.fex :P
<Turl>
(or bin, it doesn't care)
<Superpelican_>
Do you mean I should add dram_pov_protab2xxl.c to boards.cfg?
<Superpelican_>
and what should I do with script.bin?
<Superpelican_>
Do I don't have to put it on the sd card at all?
<Superpelican_>
I was able to boot the tinycorelinux image for allwinner a10 just by replacing the script.bin with the script.bin I copied from my tablet
<Superpelican_>
So maybe the meminfo is not incomplete in my script.bin
<oliv3r>
you generate dram_board.c by hand/from fexc
tzafrir has quit [Ping timeout: 264 seconds]
<oliv3r>
but you write have to manually enter the parameters in the script.bin; based ona 10meminfo
<Superpelican_>
oliv3r:But what does "data must follow a section" mean
<Superpelican_>
I couldn't convert my script.bin to a script.fex
<mripard_>
oliv3r: looking at the implementation, it makes no difference.
<Superpelican_>
oliv3r:I've now used hramrach__'s link and added -b sunxi-current flag
<Superpelican_>
oliv3r:for Protab 2 XXL support
<oliv3r>
mripard_: well it's HIGHYL confusing
<oliv3r>
Superpelican_: should work :)
<Superpelican_>
oliv3r:Which branch should work?
<Superpelican_>
I assume you mean sunxi-current?
<Superpelican_>
at least "PoV_ProTab2_XXL" is in boards.cfg
<Superpelican_>
so I've got the right branch
<Superpelican_>
need to love
<Superpelican_>
*leave ;)
<mripard_>
oliv3r: well, maybe it's for futureproofness, or for historical reasons.
<Superpelican_>
thanks for all the help
<oliv3r>
mripard_: I guess ;)
<mripard_>
if you feel like it's confusing, send a patch, and see the comments :)
<oliv3r>
must be historyical
Superpelican_ has quit [Quit: Quassel was closed]
<oliv3r>
mripard_: i hope that it doesn't really 'scan' for memcpy/sprintf, but does some other checks somehow to identify bin/text versions? because I don't need memcpy (nor sprintf)
<mripard_>
"scan for memcpy" ?
<mripard_>
what are you talking about?
sanka has quit [Quit: Leaving]
tzafrir has joined #linux-sunxi
sanka has joined #linux-sunxi
Superpelican has quit [Quit: Leaving]
<oliv3r>
i'm searching through the sources on how it decides which type it is
<techn_>
oliv3r: why you commited only sunxi-current?
<techn_>
sunxi and sunxi-current has almost same content nowadays
<oliv3r>
can do
<oliv3r>
i'll cherry pick and commit that one too
<techn_>
hmm.. we should rebase sunxi-bsp to point latest sunxi
<techn_>
It is working atleast for me :p
<techn_>
I have some felboot stuff done for sunxi-bsp, but it starts to be too ugly :(
<oliv3r>
hehehe
<oliv3r>
i have done some 'mainline' stuff on the bsp
<oliv3r>
but that needs heavily commented on :)
<techn_>
It starts to require better/wider configuration system.. or something
<oliv3r>
yeah
<oliv3r>
thanks for voulenteering :)
<techn_>
yeah.. I already did some study of bash dialog :p
<oliv3r>
:p
paulk-desktop has quit [Quit: Ex-Chat]
<techn_>
but then again.. if we add everything there, we could be using bb/yocto
<oliv3r>
well we want a system that only setups the proper files
<oliv3r>
which crosscompiler, which config file; build all
<oliv3r>
i think the bsp does what it needs to do atm quite well
<oliv3r>
i'll push my WIP
<oliv3r>
(to my personal github)
<oliv3r>
hmm, maybe tomorrow; need to do a little to much for it now :)
rz2k has quit []
<oliv3r>
mripard_: so if I use DEVICE_ATTR, the .store function can be NULL i hope; but the .show function, can I use exactly the same one? If I use the regular .show function attributes, i miss the rather important 'size' and 'pos' parameters
jemk has quit [Ping timeout: 248 seconds]
<mripard_>
are they?
<mripard_>
(important)
<oliv3r>
well
<oliv3r>
yeah
<oliv3r>
:p
<oliv3r>
pos is what we ask for
<oliv3r>
i mean, pos + size is the requested bytes from the eeprom
<mripard_>
we're talking about 16 bytes here, right ? :)
<oliv3r>
that's hardly the point!
<oliv3r>
but yeah :(
<mripard_>
anyway, you shouldn't discuss this with me, but with gkh
notmart has quit [Quit: notmart terminated!]
[hawk] has quit [Read error: Operation timed out]
[hawk] has joined #linux-sunxi
<oliv3r>
mripard_: also true, but i'll only ask stupid questions