<ssvb>
oliv3r: or alternatively a simple memset benchmark is very easy to implement in just a few lines of code
<ssvb>
oliv3r: if the buffer is large (at least bigger than a few megabytes), then you should get ~1.6GB/s speed with the current u-boot and ~2GB/s with the cubie firmware
<jemk>
ssvb: take a look at mbus clock (ccm reg 0x15c). they are different too, and if it realy means something like memory bus there could be a reason
ibrah has joined #linux-sunxi
<jemk>
and the relation 300mhz at nand and 240mhz at uboot matches the 2gb/s to 1.6gb/s
rz2k has joined #linux-sunxi
<oliv3r>
i merged all settings from boot0, so it should be identical
<ssvb>
jemk: that's a good point
<Turl>
I wonder what's A31 mem perf like :)
<Turl>
jemk: is there any document with a20 clocks?
<oliv3r>
i do have to double check the defines, as i think i've put up pll5
<ssvb>
jemk: yes, that was it, now I get 2GB/s with u-boot
<oliv3r>
so you fixed it ssvb?
<jemk>
:( sad, then my a10 cant get more speed this way.
<oliv3r>
ssvb: you changed SRC_PLL5 to SRC_PLL6 in that line i pasted ^
<ssvb>
oliv3r: just as jemk noticed, the current u-boot has it as "(0x1 << 31) | (0x2 << 24) | (0x1)", I changed it to "(0x1U<<31) | (0x1<<24) | (0x1<<0) | (0x1<<16)" from boot0
<Turl>
well it does exist
<Turl>
I did devmem 0x01c2015c 32 0x80000000
<oliv3r>
ok but my branch has 0x1 << 24
<ssvb>
oliv3r: your cleanup branch probably needs an ifdef for sun7i there
<oliv3r>
(bit 24 is pll)
<Turl>
and now my perf is crap :D
<Turl>
58MB/s C fill
<oliv3r>
of course it exists, it has to
\\Mr_C\\ has joined #linux-sunxi
<ssvb>
Turl: :)
<Turl>
oliv3r: this is an A10S
<oliv3r>
oh yeah
<oliv3r>
but still a10 has to have it too
<Turl>
let me check in my mele
<jemk>
but at least not at 0x15c, writing there doesnt change anything, readback 0
<oliv3r>
ssvb: i lie, I have 2 << 24; e.g. pll5
<Turl>
ah, I don't have any cool tool to poke memory on it
<oliv3r>
i'll check the lichee source
<Turl>
oliv3r: PLL5 is the dram pll
<Turl>
so they're kinda synced if you do that
<oliv3r>
well appearantly, a20 likes pll6 *2
<oliv3r>
ssvb: ifdef-ed it and pushed it
<Turl>
pll6 is sata :P
<oliv3r>
performance numbers don't lie!
<ssvb>
oliv3r: have you verified the performance?
<oliv3r>
mbus might be fixed in stone on a10
eebrah is now known as eebrah|away
<oliv3r>
ssvb cubies are tucked away :(
<oliv3r>
i think a10's mbus simple is hardcoded and not exposed
<oliv3r>
something they changed in sun5i
<jemk>
downclocking a10 to 816mhz instead of 1008mhz gives almost 200mb/s extra memset perf
<jemk>
then axi is divided by 2 instead of 3, so its much faster
<jemk>
do we have any official upper limit for axi clock?
<ssvb>
I think there are comments about 450MHz in the sources
<jemk>
1008/2>450 :(
<ssvb>
well, but that's not too much higher
<ssvb>
dram is already overclocked in cubie 400 -> 480
<Turl>
devmem 0x01c20120 32 0x80004900
<Turl>
devmem 0x01c2015c 32 0x81000000
<Turl>
hangs the board :(
Superpelican has quit [Ping timeout: 252 seconds]
auxym has joined #linux-sunxi
<auxym>
is it possible to chroot from opensuse into a debian-armhf rootfs with qemu
<auxym>
?
<Turl>
auxym: yes
<auxym>
opensuse doenst appear to have static qemu though. im getting /bin/bash not found right now. ill keep digging around i guess
<Turl>
on debian there's a package with static qemu which also sets up the binfmt part
<auxym>
yeah... thats the problem. im running opensuse so i cant get that debian package
<Turl>
you could download it, unpack it and use the binaries though
<Turl>
they're static after all :)
<Turl>
ssvb, oliv3r feeding A10S off "PLL6*2" doesn't seem to work, even when PLL6 is on bypass mode (which should be like feeding off osc24M, which works)
<Black_Horseman>
is there any "how to" showing how i can add on cubie an on/off switch????? and how i can power up cubie with usb hub and hdd????
<Black_Horseman>
with one power supply and cable?
<Black_Horseman>
thank you for your time, in advance
<hramrach__>
there is no easy way to add another power switch, sadly
<hramrach__>
what hdd do you want to power?
<hramrach__>
a SSD would run fine off Cubie with the provided SATA cable and decent power supply
<hramrach__>
for rotating HDD you better get a beefy power supply that gives like 5V/3A and connect both HDD and cubie to the PSU with some split cable or connect the hub the the PUS and power both cubie and HDD off hub
derethor has quit [Read error: Connection reset by peer]
derethor has joined #linux-sunxi
<jelly-home>
s/would/does/ for me
<jelly-home>
tried an old 2.5" 5400 hdd and it worked as well
<hramrach__>
some disks can spin up wihtout requiring horrendous amount of power and som just can't
<hramrach__>
after all, they were desgned for notebooks which can give more than 1.5A power to them. It just drains the battery.
<hramrach__>
then you connect them to USB port and they won't spin up
<hramrach__>
well, SSDs don't spin up so it would be odd if they did not work
Superpelican has joined #linux-sunxi
eebrah is now known as eebrah|away
<Black_Horseman>
bsck
Superpelican has quit [Read error: Connection reset by peer]
<Black_Horseman>
hramrach__ at the shop that sells cubie told me that 5V/2.1A will be adecuate for a 2.5" hdd an keyboard and mouse
<hramrach__>
it depends on the HDD and the quality of the PSU
<Black_Horseman>
but i want also to power up a usb hub for gamepad or joystics
<hramrach__>
if you already have the PSU you can just try how it works
<Black_Horseman>
well i do not have the parts yet
<Black_Horseman>
i am waiting to be paid my salary first
rz2k has quit []
<hramrach__>
I ordered some power brick from DX but it did not come so I bought a 35W PSU at a local store instead and it works well
rz2k has joined #linux-sunxi
<libv>
hivemind...
<hramrach__>
35W is a bit overkill for a single board but I want to power pretty much anything 5V for what I can find an USB cable off it
<libv>
any ideas on what the lima driver should use to detect that it is running on sunxi?
<rz2k>
dmesg | grep chip-id
<hramrach__>
cpuinfo has arch too
<libv>
hrm, smells a bit funky to do that from a C library
<libv>
but just that this is sunxi and not for instance exynos or another platform
<hramrach__>
cpuinfo should be good enough
<libv>
the existence of "/dev/disp" seems a bit... ...awkward...
<rz2k>
yes then cpuinfo
paulk-desktop has joined #linux-sunxi
<hramrach__>
there should be better place than that but don't think Linux grew something for hw identification
<hramrach__>
you get
<hramrach__>
Hardware: sun4i
<hramrach__>
in /proc/cpuinfo
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
<Turl>
libv: proving for /dev/disp should be enough I'd say
<Turl>
b*
<Turl>
(that's why you want to know if it's sunxi or something else right?)
<libv>
it's the difference between trying to use ump and mapping the fb directly
<Turl>
old(ish) exynos used ump too from what I know
<Turl>
mixed with fimc and other stuff
<Turl>
in any case, you can abstract the check and expand it later on if e.g. /dev/disp disappears
wingrime has quit [Ping timeout: 252 seconds]
<oliv3r>
libv: if you want to probe from userspace, i don't think you can yet (reliably) we have some soc-detect stuff in amery's branches, but haven't exported that to userspace. with mainline you can ask the device-tree
<oliv3r>
with 3.4 .. tehre's ways, but i think your limited to /proc/cpuinfo from userspace; unless you don't mind probing registers :) then the sramc reg is pretty clear
<oliv3r>
Turl: seems to confirm, that sun4i has mbus hardcoded and not modifyable, and only sun5i exported those settings
rz2k has quit [Ping timeout: 264 seconds]
<oliv3r>
what I don't understand, is that our current u-boot-spl, sets the mbus registers for both; when really, for sun4i it shouldn't touch them.
Soru has quit [Ping timeout: 264 seconds]
soul has joined #linux-sunxi
Soru_ has joined #linux-sunxi
soul has quit [Ping timeout: 252 seconds]
<Turl>
oliv3r: it's all 0, maybe gets lost on the bus?
gzamboni has joined #linux-sunxi
<ssvb>
oliv3r: what can be done about this? to be honest, these dram initialization antics are yet another unpleasant surprise for me :)
<Turl>
oliv3r: the sun5i one seems pretty worthless, PLL6*2 does not seem to work at all
<Turl>
at least during my trials today, it always hanged the board, even if pll6 was super slow
<Turl>
switching to osc24 worked fine, but why would you want to do that? :P
Soru_ has quit [Read error: Operation timed out]
<Turl>
ssvb: have you tested sunxifb on A20?
<ssvb>
Turl: yes, there should not be any problem with it
<ssvb>
right now it fails the disp version check and refuses to use any sunxi features
<Turl>
ssvb: how does it perform compared to A10?
<Turl>
ah
<Turl>
did AW rework disp much?
<ssvb>
at least G2D seems to be exactly the same as in A10
<ssvb>
which unfortunately means that there is still no premultiplied alpha support :(
Soru has joined #linux-sunxi
<ssvb>
I had some hopes for it, because I mistakenly looked into sun6i sources and assumed that sun7i should have the same upgrade for G2D
<oliv3r>
ssvb: what do you mean exactly
<ssvb>
Turl: the version check ioctl is an extra linux-sunxi feature, it does not mean that the disp hardware is different
<ssvb>
Turl: it's just that we are a bit too paranoid and don't want to use unknown disp stuff without checking it first
<ssvb>
Turl: I believe that we should not have any problems with disp
<ssvb>
oliv3r: about what?
Soru__ has joined #linux-sunxi
<oliv3r>
21:49 < ssvb> oliv3r: what can be done about this? to be honest, these dram initialization antics are yet another unpleasant surprise for me :)
<ssvb>
oliv3r: nevermind, it's more like the case of "you don't want to know what happens at the sausage factory" :)
<ssvb>
now I know a little bit more, and it makes me sad
Soru has quit [Ping timeout: 276 seconds]
<oliv3r>
ssvb: ah, yeah
<oliv3r>
well that's only for a10
<oliv3r>
and imo, a10 is kinda obsolete
<oliv3r>
sure we can't beef up performance more
<oliv3r>
but our efforts should be focused on a20 for now
<oliv3r>
and any performance gain we can get for a10, is nice to have
<oliv3r>
i would think, put model number in the high 64 bits, and the bit that looks the most like a serial in the lower half
<oliv3r>
it's supposed to come like that from the AW factory
<oliv3r>
but somehow AW sells 'unmarked' chips
<libv>
it seems like something that will not help anyone
<libv>
"Hardware: sun%di" is enough for lima
<libv>
and i think few other userspace programs need to know more detail
<oliv3r>
what does the hardware: say right now? sunxi or sun4i
<libv>
the latter
<oliv3r>
ok
servili007 has joined #linux-sunxi
<oliv3r>
my guess, is that's it's a compile time thing atm
<oliv3r>
e.g. fixed string
<oliv3r>
not an issue for you right now :)
<libv>
all i need to know is hot to properly access fb
<oliv3r>
but a unified kernel will have issues with that :)
<libv>
s/hot/how/
<libv>
unified kernel can only happen with dt i guess
<libv>
man... it's going to be a really smell mess.
<oliv3r>
actually, we are quite far
<libv>
ah, for sunxi?
<libv>
i do not care beyond sunxi tbh
<oliv3r>
yeah for sunxi of course
<oliv3r>
other socs, mainline yeah
<servili007>
hey guys, I've been making my own debian debootstrapped builds. Trying to switch to linaro now, but once x starts, I just get a blinking cursor. Is it attaching to the wrong display? building 3.4 kernels with mostly stock sun4i config, same result on 3.0 iirc and across 3 different sun4i devices
<libv>
so playing with cpuinfo for sunxi seems both awkward and not really useful atm
<libv>
servili007: have you read /var/log/Xorg.0.log ?
<libv>
servili007: have you followed the binary drivers guide properly?
<oliv3r>
libv: i guess there isn't much that can be done really until mainline comes with dt
jlj has joined #linux-sunxi
<servili007>
libv: if it's the same issue I had when I tried this in the past, logs will come up with screen not found. I'll verify shortly. I'm using the BSP running through updated submodules and my edits. It should be building everything properly. Debian sure seems to think so anyway
<libv>
oliv3r: and until that kernel has become ubiquitous
<libv>
servili007: work through binary drivers
<libv>
servili007: that is older than the bsp, iirc
<servili007>
libv:I thought bsp builds them for you at hwpack install?
<libv>
err
<libv>
more recent
<servili007>
okay
<jlj>
is there a way to make a hwpack with the 3.4 kernel when using sunxi-bsp builder?
<servili007>
jlj: yeah, you checkout 3.4
<jlj>
servili007: do you know the syntax? like "make kernel34" or such?
<servili007>
enter the linux-sunxi folder and do a git checkout origin/sunxi-3.4
<jlj>
ah okay
<jlj>
and then just run make again?
<servili007>
yep
<jlj>
okay, thanks!
<servili007>
I'd clean up first
<servili007>
switch over
<servili007>
then reconfigure/rebuild
<jlj>
ok
<jlj>
by the way do you know a rootfs that has a ssh server running by default?
<jlj>
seems like it's turned off in linaro
<libv>
jlj: it is disabled in all basic debians
<jlj>
libv: I kinda thought so :|. well ok
<libv>
but i do not know an answer to that question myself
naobsd has quit [Quit: Page closed]
<libv>
i was lucky enough to always haev serial so far
<servili007>
I jumped for a cubieboard right when the a20 came out. Wanted to kick myself but I love sun4i lol
<servili007>
and not having to solder my own serial etc is nice
<servili007>
of course, I wouldn't love the a10 at all without the linux sunxi project :P
<Turl>
newer kernels have the SoC bus to expose all this info
<oliv3r>
Turl: lsbus?
<Turl>
no, something on /sys you can cat though
<Turl>
oliv3r: I linked you to a patch to add it some time ago
<Turl>
libv: can't you just feature probe? if(file_exists(/dev/ump)) use_ump() else alloc_fb()
<libv>
oliv3r: i am quite well aware that samsung is hiring
<libv>
have been so for 6m now
<oliv3r>
WORKSITE LOCATION
<oliv3r>
Suwon, South Korea
<libv>
but i refuse to move
<oliv3r>
hehe
<oliv3r>
i imagine
<libv>
i would be moving every 2 years
<oliv3r>
moving to s. korea is pretty big
<libv>
for _no_ reason
<libv>
i already moved for SuSE
<libv>
and i got not even 23 months out of that one
<libv>
despite bringing them a pile of AMD cash
<libv>
then i was at nokia for a bit...
<libv>
and we all know how that went
<Turl>
:P
<libv>
so no, no matter how big the company, i do not move anymore.
<oliv3r>
i don't blame you
<oliv3r>
libv@samsung.com :)
<oliv3r>
but yeah not only is it far away
<oliv3r>
s. korea, language etc
<oliv3r>
family far away
<libv>
they better accept me working from home and travelling 25% of the time, or they are getting to keep the sort of idiots who messed up exynos4 fb support
<oliv3r>
partner who might not want to
<oliv3r>
libv apply with that notion ;)
<libv>
my gf will follow me wherever i move to, but i do not want to put her through that
<libv>
i do not want to put myself through that either
<libv>
life here in nue is good, loads of fun linux geeks around
<libv>
moving is just pointless
<libv>
for open source work, you should be used to working from home, provided that you do not become too lonely and demotivated at said home
<oliv3r>
will you ever move back to .be?
<libv>
and travelling once every X weeks for teammeetings is actually fun
<libv>
because that ends up being a whole week of just the team and nothing else
<libv>
if the right balance is found, it is a fantastic way of working
<libv>
(meego graphics adaptation team was great for that, other teams inside meego were not as good)
<oliv3r>
well flying to s. korea a few times a year from .de can be quite pricey
<libv>
oliv3r: not very likely
<libv>
oliv3r: does not need to always be korea
<oliv3r>
well in samsungs case :p
<libv>
and the "not very likely" is me moving back to belgium
<libv>
belgium is a flat and wet place
<oliv3r>
lol
<libv>
with few linux geeks
<oliv3r>
what about left behind friends+family
<libv>
i visit family a few times per year, and family tends to visit here quite often
<oliv3r>
oh 3.10 is out
<oliv3r>
bed time though
<oliv3r>
nn :)
<libv>
few friends remain after 6 years, people move on
* Turl
git syncs
<libv>
anyway, think thoroughly before accepting a job that requires that you relocate
<libv>
or one that requires that you are nda-ed up from here to eternity and that you will end up not being able to do any proper open source work anymore in future
<libv>
these days you are lucky if you have a big company pay you for more than 2 years
<libv>
and if you relocated or signed away your work and an external future... then that's it.