<rinni>
wens: thanks, I'll try them on the weekend. I guess I only need commit 'hwmon: AXP20x: Add support for basic voltage/current/temperature ADCs', right?
<wens>
now why would you look at an old revision of the page?
<Johnson>
wens: 'cause the current one has no details about manual building
<Johnson>
It's the only info I could find. So I don't know which target I need now
petr has quit [Ping timeout: 264 seconds]
jebba has joined #linux-sunxi
petr has joined #linux-sunxi
<wens>
Johnson: that's because no one bothered to do the NDH stuff and make it available i guess
seppel has quit [Quit: Leaving]
<wens>
the 'sun7i' target is for allwinner's sdk, not sunxi
<wens>
hence it was removed
<Johnson>
wens: Makes sense. Is the NDH stuff doable by myself?
<wens>
yes, follow the guide
<Johnson>
wens: If I already have a sys_config.fex from the manufacturer. Could I skip certain parts?
<wens>
if you're sure it matches the device
bertrik has joined #linux-sunxi
akaizen has joined #linux-sunxi
<Johnson>
wens: I'm 99% sure. It was used by the manufacturer to make images. I'll walk trough the NDH when this fex fails. But where in the process do I need to start when I assume that the fex file is correct?
<rinni>
wens: I applied the patches from your axp209-hwmon branch but I can't figure where to find it in /sys
<libv>
Johnson: just walk through the ndh guide completely
<libv>
Johnson: you're just wasting your own and our time otherwise
<wens>
rinni: you still have to enable the driver
bertrik has quit [Ping timeout: 255 seconds]
<wens>
rinni: anyway i haven't used them in a while, maybe they were broken after i rebased them
<rinni>
wens: I did that... OK; I try to check some more... thanks!
FDCX has quit [Remote host closed the connection]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
FDCX has joined #linux-sunxi
alexst has joined #linux-sunxi
bertrik has joined #linux-sunxi
alexst has quit [Ping timeout: 264 seconds]
_massi has quit [Quit: Leaving]
rz2k has joined #linux-sunxi
bertrik has quit [Ping timeout: 240 seconds]
bertrik has joined #linux-sunxi
bertrik has quit [Ping timeout: 240 seconds]
kivutar has quit [Quit: Ex-Chat]
bertrik has joined #linux-sunxi
imcsk8 has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
paulk-collins has quit [Quit: Ex-Chat]
alexst has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
imcsk8_ has joined #linux-sunxi
apo_ has quit [Ping timeout: 272 seconds]
alexst has quit [Ping timeout: 240 seconds]
jebba1 has joined #linux-sunxi
paz_ has joined #linux-sunxi
zoobab_ has joined #linux-sunxi
ssvb_ has joined #linux-sunxi
fredy_ has joined #linux-sunxi
<Johnson>
I'm gonna take my time to do the whole NDH for the PhoenixA20. When I try to get the DRAM info i get this message: /system/bin/sh: a10-meminfo-static: not found. Any ideas on whats going wrong?
<Johnson>
The file is in the directory. I pushed it there and I can see it when I "ls"
<Johnson>
I chmodded it aswel, but it doesn't work
oliv3r_ has joined #linux-sunxi
imcsk8 has quit [*.net *.split]
jebba has quit [*.net *.split]
zeRez has quit [*.net *.split]
zoobab has quit [*.net *.split]
paz has quit [*.net *.split]
fredy has quit [*.net *.split]
ssvb has quit [*.net *.split]
oliv3r has quit [*.net *.split]
<Johnson>
Nevermind, I'm an idiot
jinzo has joined #linux-sunxi
<Johnson>
Had to tell bash that it was in the current directory.
apo__ has joined #linux-sunxi
zeRez_ has quit []
Zboonet has joined #linux-sunxi
apo_ has joined #linux-sunxi
apo__ has quit [Ping timeout: 245 seconds]
<Johnson>
libv: If the DRAM doesn't output a size for in the DRAM file, is it safe to leave it at 1024?
<Johnson>
".size = 1024" is the entry i mean :)
apo__ has joined #linux-sunxi
apo_ has quit [Ping timeout: 256 seconds]
Zboonet has quit [Remote host closed the connection]
<Turl>
Johnson: that's the RAM size
<Turl>
1024 is 1G
Zboonet has joined #linux-sunxi
<Johnson>
Turl: Okay that means that 1024 is correct. I think I'm making progress. Do you mind if I hit you up with any additional questions I might have tonight? :)
<Turl>
sure, just ask them here, I'll probably be around
<ssvb_>
Johnson: the dram size parameter is not used by u-boot
<ssvb_>
but you can set it to something reasonable
Zboonet has quit [Read error: Connection reset by peer]
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
Zboonet has joined #linux-sunxi
Zboonet has quit [Remote host closed the connection]
<Johnson>
Turl: Tried building uboot after going trough the steps of adding the needed info. It says it can't find configs/a20_phoenix.h Is this a file I also need to create?
<Turl>
I've never seen that one
<Turl>
can you paste the output of git diff?
afaerber has quit [Quit: Verlassend]
montjoie[home] has quit [Quit: leaving]
alexst has joined #linux-sunxi
montjoie[home] has joined #linux-sunxi
<Johnson>
Turl: Ah, that is the only step I didn't do. Pushing to the repo. Is this essential for it to work?
fredy_ is now known as fredy
alexst has quit [Ping timeout: 240 seconds]
fredy is now known as Guest25693
Vanfanel has joined #linux-sunxi
<Vanfanel>
Hi, cubietech people: Will MALI binary drivers r4p0 ever be released for Cubietruck/Cubieboard2? Current r3p2 is horribly outdated
Johnson has quit [Quit: Page closed]
rinni has left #linux-sunxi [#linux-sunxi]
<Turl>
Vanfanel: you'd be better off asking that on their forums or via email I suppose
<Turl>
this is a community channel
<Turl>
Vanfanel: any reason why you want newer blobs btw?
<Turl>
they tend to have new ugly bugs as well
<Vanfanel>
Turl: r3 ones are very slow
<Vanfanel>
uploading a texture is SLOOOW
<Vanfanel>
I've heard r4 is way better
<Turl>
I seriously doubt a new blob will make such operations any faster
<ssvb_>
Vanfanel: how are you uploading textures?
<Turl>
but you can ask libv :)
<libv>
Vanfanel: why is it outdated?
<ssvb_>
Vanfanel: maybe you should have a look at the compositing window managers, such as kwin_gles to see how they are successfully using the Texture from Pixmap extension?
<libv>
hrm, so uploading a texture is slow, i am not sure why that should be so
<libv>
the code for properly ordering a texture so that the fragment shader can more easily interpolate is pretty hard to make any faster
<libv>
so it might be that this was disabled
<libv>
which gives you a slow upload, but a few percent off of your framerate
<libv>
chose your poison.
<Vanfanel>
libv: it's slow on MALI, not on LIMA. Are you also working on MALI?
<Vanfanel>
ssvb_: using GLES2. Nothing fancy. I found out because RetroArch, which has performance counters, says image drawing is taking a lot of time versus, let's say, Raspberry pi
<libv>
Vanfanel: are you using this swizzling on lima?
<ssvb_>
Vanfanel: are you using GLES and texture upload in exactly the same way on the Raspberry Pi?
<ssvb_>
Vanfanel: there are dumb and clever ways to do the same thing, please double check that the Raspberry Pi does not have a shortcut to offload some scaling work to the display controller instead of using GLES
<ssvb_>
Vanfanel: based on your complaints that I keep hearing for maybe half a year already, RetroArch only needs primitive scaling
<ssvb_>
Vanfanel: anyone with half a clue could have resolved this problem ages ago
<libv>
urgh, that's terrible
<libv>
why can people not learn to use the right tool for the job?
alexst has joined #linux-sunxi
KEPTEIN has joined #linux-sunxi
<libv>
and then complain by stating that one thing is "outdated" and then go straight on to complain that texture upload is faster with the newer one
<libv>
what is it, outdated, or is just texture upload faster?
<KEPTEIN>
Hi guys, i just disassembled my novo7 with hope finding UART RX/TX ports, and i think i did.
<Vanfanel>
with certain non-GLES2 extension, it could be faster (glTexSubImage2D()) but both boards are plain GLES2 with no special extensions
<libv>
Vanfanel: tell me that you are joking.
<libv>
Vanfanel: you are comparing an A20 with an exynos4 quad?
<Vanfanel>
libv: no, just the image uploading part, not the emulation
<Vanfanel>
obvously exynos4 quad runs circles about the poor A20 for emulation
<libv>
Vanfanel: don't you think that a quad A9 at 1.8GHz is going to be a tad quicker at swizzling a texture than a dual A7 at 1GHz?
<Vanfanel>
but RetroArch's performance counters are separated
<Vanfanel>
libv: yes and no. The A20 is supposed to be slower but not that slower... it takes almost double the time!
<libv>
Vanfanel: also, A20 has pretty poor memory bandwidth compared to exynos4
<libv>
1Ghz versus 1.8GHz
<Vanfanel>
exynos4 was also this slow with r3pX, libv
<Vanfanel>
then with r4p0 it became a lot faster
<Vanfanel>
that's why I am asking if r4p0 will come out for the Cubie2
<libv>
well, someone should go look at what the new code is doing different
<libv>
but i am not going to be on lima for the forseeable weeks
<libv>
Vanfanel: as soon as you port the r4p0 kernel driver to sunxi-3.4
<libv>
then r4p0 userspace should work
<Vanfanel>
are we stuck on a 3.4 kernel forever?
<Vanfanel>
with the CB2 I mean
<libv>
Vanfanel: not forever, but for the forseeable future
nabblet has joined #linux-sunxi
<Vanfanel>
libv: well, thans for your answers
<libv>
Vanfanel: since retroarch seems to be well instrumented, it would be nice to see the performance difference between r3p2 and r4p0
alexst has quit [Ping timeout: 264 seconds]
<libv>
Vanfanel: linux-exynos.org seems like the perfect place for a wiki page on that
bonbons has joined #linux-sunxi
<Vanfanel>
libv: on exynos it has other problems, like tiling and tearing
<libv>
what do you mean with "problem" and "tiling"?
<libv>
you see tiles in between frames?
<Vanfanel>
yes, I can see where the emulation draws frames in tiles
<libv>
this is caused by the same issue that causes tearing
<Vanfanel>
I can also see tearing and artifacts
<libv>
bad synchronization
<Vanfanel>
yes, somewhere in the code, frame swapping is not done during vsync
alexst has joined #linux-sunxi
<libv>
bad interaction of display driver, mali kernel driver, and mali userspace
<Vanfanel>
but I just want to use RA like I do on the Raspberry Pi: no tearing, no artifacts. Slow for many 16 bit systems, yes, but awesome for 8bits.
<Vanfanel>
Perfect frames
<Vanfanel>
I got the U3 and the CB2 for a better CPU, but driver support is.. well...
<libv>
Vanfanel: the thing is, you do not need the 3d engine for scaling
<libv>
Vanfanel: our display engine is pretty good at scaling
<Vanfanel>
No ne has figured out how to use G2D on U3
<libv>
sure, you don't get 4x msaa with our display engine, but it has some filtering in there
<Vanfanel>
It's the equivalent to DispmanX on the PI, as far as I understand
<libv>
display, not 2d accel
<libv>
g2d is 2d acceleration
<Vanfanel>
No, I don't need any filters or fancy fsaa
<Vanfanel>
just hardware scaling AND good video synchronization (doublebuffer, vsync)
<Vanfanel>
but so far only r3pX on the CB2, with MALI on FBDEV can do that
<libv>
my feeling is that they just disabled swizzling
<Vanfanel>
the U3 people you mean? mdrjr?
<libv>
or the arm people
<libv>
to get the speed increase
<libv>
it does require a bit of nasty cpu work, or a pass with the gpu
<libv>
hrm... let me see what the difference in call was again
<Vanfanel>
I don't know... but it's been a year, as ssvb_ said. I'm back to Rpi and fanless X86 with integrated Intel graphics. There it's just build kernel + modules and I get accelerated and perfect frames with KMS/EGL.
<libv>
Vanfanel: use glSubImage2D
<libv>
to upload the frames
<libv>
and then the driver will not swizzle
<Vanfanel>
are we talking about U3 or about CB2?
prahal has left #linux-sunxi [#linux-sunxi]
<libv>
glTexSubImage2D vs glTexImage2D
<Vanfanel>
in CB2, there's no tearing/tiling. It's on U3. CB2 is just slow on uploading.
<libv>
Vanfanel: look it up, alter the code, and bench the difference on CB2
<ssvb_>
RetroArch sources also seem to have some references to mipmaps generation, maybe this could be disabled?
<libv>
s/could/should/
<libv>
if you're just scaling and nothing else, that is
<libv>
the Q3A cut scene is done using glTexSubImage2D so that no swizzling or compression takes place
<Vanfanel>
ssvb_: can you point to what should be disabled, please?
<libv>
...
<Vanfanel>
at least with some 2-3% more free CPU, I could get fullspeed snes on the CB2
<libv>
look into using an overlay with disp
<Vanfanel>
libv: glSubImage2D? Do you mean glTexSubImage2D, right?
<Vanfanel>
an overlay, do you mean a plane like in KMS/DRM?
<libv>
Vanfanel: read a few lines down from where you got the first
<libv>
plane is intel speak
<libv>
and kms planes is a just started thought, not even an unfinished one
<libv>
but yes
<libv>
read up on how to use disp
<Vanfanel>
disp is a 2D API for MALI?
<libv>
Vanfanel: no.
<libv>
mali is a gpu or 3d engine only.
<libv>
2d is 2d acceleration
<libv>
display is something different entirely
<libv>
i think i tried to explain this to you 5 minutes ago
<Vanfanel>
look, I am not a native english speaker. You said "read up on how to use disp". I don't know what disp is. An API?
<rz2k>
[23:55:57] <libv> then r4p0 userspace should work - that wont bang because iirc theres only two r4p0 userspaces available, x11+drm+dmabuf armhf (hardkernel mali ddk + armsoc xorg) and fb armel (from amlogic).
<oliv3r>
Turl: oh, actually, that package is a some weird meta package
KEPTEIN has quit [Quit: Leaving]
<oliv3r>
Turl: it doesn't depend on owncloud nor installs owncloud
<rz2k>
libv: so as far as I understand, since we dont have sunxi-drm and all the drm things that armsoc wants, r4p0 from hardkernel will not work.
<oliv3r>
and i can't install owncloud together with owncloud-sqlite
<Turl>
did you add some other apt source to install owncloud?
<oliv3r>
says that it is only in backports anyway
<oliv3r>
nope
<Turl>
ok then
<Turl>
you should be fine
<oliv3r>
only 2 lines in my sources.list, wheezy and wheezy-backports
<oliv3r>
only the main suits though
<oliv3r>
if should just pull in the backports version, but it seems to ignore it
<HeavyMetal>
hi I am wondering if anyone got Linux to boot from the NAND of an A10 device? I am trying to get the MK802ii to boot from the NAND but so far it is not happening