<mnemoc>
akaizen: as you seem to be interested in the quality of the wiki and you seem to have experience with mediawiki I was wondering if you would like to make an infobox template for the specs of our devices. I started constructing one with http://linux-sunxi.org/Cubieboard
<akaizen>
mnemoc: I have no experience with mediawiki but would be happy to take a crack at it
<mnemoc>
akaizen: cool
<mnemoc>
rm: just added syntax highlighting to your script
<mnemoc>
rm: thanks
<mnemoc>
akaizen: basically the next step is to create a more semantic template taking args like `sata = yes` and use {{Infobox}} to give a uniform look and feel to the descriptions of all sunxi devices on the wiki
<akaizen>
ok, I was looking at examples like PS3 and other wikis for a good look
<mnemoc>
:)
popolon has joined #arm-netbook
ceo16uf has quit [Ping timeout: 256 seconds]
cheng has quit [Quit: Leaving]
<jlj>
rm: how do I check if cpu scaling is enabled? /proc/cpuinfo says it is 59.63 bogomips which seems a little low
<rm>
so it is enabled
<rm>
maybe you're even running on a conservative governor
<lundman>
gidday gov'na
<rm>
hm I should change the script not to require cpufrequtils
<jlj>
uh uh.. so that would explain the heavy top usage. I'll check the setting you wrote earlier, was away for a bit
<jlj>
rm: kay, I just wanted to see if there is a way to see the current settings first
<jlj>
rm: like what cpu frequency it's running at default
ceo16uf has joined #arm-netbook
<rm>
see files in /sys/devices/system/cpu/cpu0/cpufreq/
<jlj>
rm: I ran cpufreq-info
<jlj>
rm: current CPU frequency is 60.0 MHz.
<rm>
okay that works even better
<jlj>
rm: lol, so yeah that would explain it
<lundman>
that's like 60 C64s
<jlj>
rm: well guess it takes 6 c64s to run top then :)
<jlj>
rm: anyway so you were right about the scaling causing it, thanks, I'll check out the script now
<lundman>
heh true
<jlj>
rm: so what do the 3 last lines in the script do?
<jlj>
rm: makes it scale up faster and down slower?
<rm>
make it ramp up the frequency faster and clock down much more reluctantly
<jlj>
rm: ah, yeah
<rm>
and also consider IO as busy which I think is a good idea here
<rm>
google the file names for detailed documentation on each
<jlj>
rm: okay..
<jlj>
so if up_threshold was 95 before it needed to be fully loaded for it to consider to speed up.. yeah, no matter it felt slow
<mnemoc>
akaizen: keep in mind we have two clearly identified SoCs, a10 and a13, and there is no much point in repeating their features when writing the infoboxes of each device :)
<akaizen>
Yea, i dont think its possible to have a generic drop in for SATA | Yes
<akaizen>
but i think you can have a bunch of fields and have the conditional as you use them
<jlj>
rm: set the cpufreq to 1ghz and top is down to 1-2%. so case closed I think :)
<rm>
yeah
<jlj>
rm: thanks :)
<rm>
I wonder still why the "Load" is constantly 1.00+
<jlj>
rm: which load?
<mnemoc>
akaizen: my comment was more about a soc = a10 instead of having cpu/gpu/vpu fields
<rm>
shown in top
<rm>
or in 'uptime'
<rm>
"load average"
<akaizen>
I added both ;)
ceo16uf has quit [Ping timeout: 265 seconds]
Quarx has quit []
TomNL has joined #arm-netbook
<jlj>
rm: my load average says 0.36, 0.23, 0.17 now
<rm>
nice
<rm>
which kernel version?
<TomNL>
hey guys, did anyone test xbmca10? i was playing some files over samba but seems to be a bit jerky
<jlj>
rm: kernel 3.0.42+
<rm>
ok
<rm>
I tried only up to 3.0.39
Quarx has joined #arm-netbook
<jlj>
okay, well it seems fine in this version. seems reasonable, was running a few things then
<TomNL>
lundman: did you test some playback of files?
<cat1>
is there any way to detect presence of axp20 regulator programmatically?
<mnemoc>
cat1: recently a google translation of the datasheet was pasted on the wiki...
tzafrir_laptop has joined #arm-netbook
<mnemoc>
cat1: also, the sun5i branch has some changes in those drivers you may want to look if you are going to dive into the regulator
<mnemoc>
cat1: but everything just assumes an axp209 is used
<cat1>
mnemoc: except for hardware itself does not make such assumption ;)
<jlj>
rm: read around abit and it seems someone said that frequency governor "fantasy" should make things a bit snappy too. haven't tried it yet though
<rm>
afaik this one is Allwinner's own invention
<rm>
it's not in the mainline
<rm>
so I do not trust it
<cat1>
rm: +1
<jlj>
rm: yeah, the name sounded a bit shady lol
<mnemoc>
iirc fantasy is a variant of interactive
<cat1>
btw, which governor is used by ICS?
e-ndy- is now known as e-ndy
<rm>
wtf is "interactive"
<rm>
not in the mainline either
<mnemoc>
android's default governor
<rm>
well, I could understand the need for finer fiddling on tablets, but my involvement with A10 is currently only "HDMI Sticks" and the Mele :)
<rm>
ondemand works well on those
<lundman>
wha
<rm>
nothing to wha about
<rm>
:))
<cat1>
very optimistic question: is there any way to flash sd card via usb w/o removing it from e.g. mk802? Some tricks in das u-boot?
<rm>
very confusing question I'd say
<rm>
SD card is not on USB in mk802; flash... from what? from the MK802? while running what... Android? booted from where... NAND or that SD card itself?
<cat1>
rm: i'll try to rephrase it: can i flash new kernel to SD card w/o removing it from target device? analogy is flashing fimware in to n900, n9
<rm>
kernel is just a file on a FAT partition on the SD card
<rm>
you mount it, put the new file instead of the old one
<rm>
# ls -la /boot/uImage
<rm>
-rwxr-xr-x 1 root root 2931636 Aug 20 22:23 /boot/uImage
<rm>
that's while being logged in on my MK802
<rm>
and that's its current kernel
<rm>
"flashing fimware" is a bad analogy
<rm>
SD card is seen just like a simple HDD
<rm>
because A10 is awesome like that
<cat1>
rm: basically i have an experience working with such a bootloader that allows you to write into sd card w/o the latter being removed from target. the thing is that it is slightly annoying everytime you change kernel toss with sd card removal. I am pretty much sure it must be possible to do it seamlessly. just need to find a way to transfer kernel image over usb to u-boot and let it put that image into sd card.
<rm>
ah, you mean with the device itself being unbootable
<rm>
or paused at u-boot
mSquare has left #arm-netbook [#arm-netbook]
mSquare has joined #arm-netbook
<rm>
yes I agree that would be nice
<mnemoc>
tig
<mnemoc>
err
<mnemoc>
OT: do you know a good stgit tutorial/guide ?
mtd_ is now known as mtd
Almamuetya has joined #arm-netbook
calris has joined #arm-netbook
calris has quit [Client Quit]
calris has joined #arm-netbook
* calris
is in a quantum state
<mnemoc>
mental note, you can't use the same usb extension cable for powering+otg and for the usb/uart dongle
* mnemoc
needs a two floors desk :|
<cat1>
mnemoc: on mental note: what about host usb?
<mnemoc>
cat1: what do you mean?
<mnemoc>
extension cables only have one connector on each side, so to connect one device you disconnect the other
<mnemoc>
but will probably search for a cheaper alternative :p
<cat1>
mnemoc: pretty much you'll one!
Gujs has joined #arm-netbook
* cat1
lacks optimism after reading allwinner code..
<mnemoc>
cat1: according to tom most is written by EEs...
<cat1>
mnemoc: EEs, who are those people? :D
<mnemoc>
those who should be writting proper datasheets instead
<cat1>
mnemoc: we need to cooperate with them.. even for free.
<mysteryname>
so you're saying that the software guys did the datasheets? :P
<cat1>
otherwise we will never see a10 upstreaming..
<mnemoc>
cat1: btw, instead of 3.6 we should try to forward port our core to arm-soc's next/multiplatform
<mnemoc>
that is basically how 3.8 will be for us
<mnemoc>
for fixes I'm still convinced about the 3.0 (stable) -> 3.4 (test) -> 3.8 (experimental, bare core only, mainlining goal) chain
<mnemoc>
cat1: what do you think?
<jlj>
so the official linux kernel doesn't have a10 support yet? or just not all of it?
<jlj>
saw the comment about upstreaming
<mnemoc>
jlj: huge parts of it need to be rewritten before trying to mainline anything
<jlj>
mnemoc: allwinner's code isn't all that great huh? well at least it seems to work pretty well
<mnemoc>
jlj: upstream linux arm has "common" ways of doing things across different platforms
<mnemoc>
while allwinner uses their own method for everything
<mnemoc>
which won't ever be accepted upstream
<mnemoc>
this is not about the quality of the code, but about the methods used
<jlj>
mnemoc: ouch, well I see how this could be troublesome
<mnemoc>
linux-arm has done huge efferts to standarize the already mainlined platforms
<mnemoc>
effort*
<mnemoc>
if we want to get in, we need to follow their rules
<jlj>
mnemoc: I guess that's good in the end
<jlj>
mnemoc: too bad allwinner didn't know/care though
<mnemoc>
jlj: they care about android devices, and android uses 3.0
<mnemoc>
once android moves forward they will hack in their support on top of whatever version android's kernel-common uses
RITRedbeard_ has quit [Read error: Connection reset by peer]
RITRedbeard_ has joined #arm-netbook
ZeroJ has quit [Ping timeout: 240 seconds]
<cat1>
mnemoc: the fixes i did so far for 3.6 should have no problems with other versions. As for upstreaming, why 3.8? (i am a bit out of sync with kernel upstream happenings).
IEF has quit [Quit: leaving]
IEF has joined #arm-netbook
<mnemoc>
cat1: basically because they are going to break the world in 3.7 imposing multiplatform (mach as bool, not choice)
<mnemoc>
that means no more #include <mach/...>, no more globals, ....
<mnemoc>
and so they provide already a "base" with all that mess
* cat1
vaguely remembers reading something about this..
<mnemoc>
also since 3.7 the use of the common clock framework and pinctrl will be mandatory
<mnemoc>
3.8 gives us 2 full cycles fo getting the core into shape
<mnemoc>
without needing to reimplement as we now know plat-sunxi is a dead end
<mnemoc>
everything shall be moved to platform drivers
* cat1
needs to think about this..
<mnemoc>
and as we won't be mainline'able in time for them to migrate our code...
<mnemoc>
we will need to do this anyway sooner than later
<cat1>
mnemoc: so off we go! :)
<mnemoc>
i currently see two entry points, pinctrl and the common clock framework
<mnemoc>
personally I'm far more confortable with the pins than with the clocks :p
<cat1>
mnemoc: i am comfortable with neither of these :D
<mnemoc>
:D
<cat1>
mnemoc: though can look into clock.. remember dealing randomly with it.
<mnemoc>
take a look into arm-soc's next/multiplatform... it's scary
<mnemoc>
then we can switch to 3.7, but not before they merge that beast
<mnemoc>
or it will hurt
<cat1>
mnemoc: is already hurts :P
<cat1>
s/is/it
<mnemoc>
:)
* cat1
thinks we need to make an offer to allwinner.
<cat1>
or actually vice versa..
<mnemoc>
dreaming awake?
<cat1>
mnemoc: in the light of being jobless, yes.
<mnemoc>
fair point. I do can still afford a hobbie
<mnemoc>
back in 20m
mysteryname has quit [Ping timeout: 240 seconds]
QingPei has joined #arm-netbook
<mnemoc>
cat1: if you mail them, please keep in mind I'm also willing to get NDAed access to code and info as long as it doesn't limit the capability of working in the public uboot/linux trees :)
<cat1>
mnemoc: i was not that serious about working with/for allwinner, i doubt they would even pay attention to my imaginary request :) But sorry for misleading you!
<mnemoc>
:)
* mnemoc
wouldn't mind... but wouldn't ask either
<ManoftheSea>
an offer?
<ManoftheSea>
this is the offer to get NDA access to their docs, as long as you can release code?
<mnemoc>
ManoftheSea: just dreaming awake
<ManoftheSea>
Wait, did 3.6 come out?
<ManoftheSea>
What's multiplatform?
<mnemoc>
not yet
<ManoftheSea>
Or rather, Is there a location that talks about these targets, where I can self-educate?
<mnemoc>
multiplatform is the largest big change in arm linux for 3.7. same kernel bin supporting any set of arm platforms
<mnemoc>
ManoftheSea: linux-arm-kernel@lists.infradead.org and the Documentation/ dir
<mnemoc>
there is also a video from arnd in LPC2012
<andoma>
anyone know if the MK802 have wired the CEC-pin in the HDMI port?
Scepterr_ is now known as Scepterr
tzafrir_laptop has quit [Ping timeout: 246 seconds]
xenoxaos has quit [Ping timeout: 256 seconds]
markvandenborre has quit [Ping timeout: 265 seconds]
pawel5870 has quit [Ping timeout: 265 seconds]
<rz2k>
techn: please dont say that you use armel system and armel mali libs from a10-bin...
markvandenborre has joined #arm-netbook
xenoxaos has joined #arm-netbook
pawel5870 has joined #arm-netbook
jelly has joined #arm-netbook
revident has joined #arm-netbook
pawel5870 has quit [Ping timeout: 245 seconds]
<VarmVaffel>
do you have to setup a nand flash chip hooked up to an ARM, or does the CPU have some pre-implemented method of communicating with the chips?
<VarmVaffel>
like if I try to write with openocd JTAG
<rm>
hmm
<rm>
is there a way to control video mode refresh rate (Hz) on Mele's VGA? :/
pawel5870 has joined #arm-netbook
<rz2k>
fbset
<mnemoc>
works?
<mnemoc>
VarmVaffel: depends on the SoC. allwinner's A10 and A13 come with a NAND controller inside
<jquip>
hey all ^_^.. just askin.. switching on the a10 tablet takes painfully long, i have to keep pressing the power button for about 10-15 secs for linux to load from mmc
<jquip>
any body else have similar issues??
<mnemoc>
"In Suspend/Resume we trust"
<cat1>
mnemoc: i know, you will hate this ;) but fyi, i just pushed updated 3.6: git@github.com:polarcat/linux-allwinner.git branch sunxi
<mnemoc>
cat1: thanks
mSquare has left #arm-netbook [#arm-netbook]
<mnemoc>
cat1: but when sending patches to the ML, can you make them against 3.4? :)
<cat1>
mnemoc: sure, but i believe that these recent ones should apply smoothly
<mnemoc>
cat1: 3.4 had script.bin voodoo removed before you sent the last patchset
<cat1>
mnemoc: btw, thanks for the link to LPC2012 video, was quite to watch it.
<mnemoc>
:)
<cat1>
mnemoc: yeah, but i guess we still need to support some sort of configurability w.r.t. fb, g2d reservations, no?
<mnemoc>
cat1: sure, it's a very valuable patchset
<cat1>
though i personally do not like it ;)
<cat1>
mnemoc: watching vide inspired me for DT..
<mnemoc>
cat1: i feel kind of unconforable prefixing the fbsize/.... things
<mnemoc>
cat1: we can't have DT before pinctrl
<mnemoc>
cat1: or it wouldn't be able to setup anything
<mnemoc>
we can do gpiolib instead, but pinctrl is now req. and gives gpiolib for free
Yakuzzi has quit [Remote host closed the connection]
sspiff has quit [Remote host closed the connection]
Yakuzzi has joined #arm-netbook
<mnemoc>
that's why I'm so annoying about fixing the drivers in 3.0/3.4 first
<mnemoc>
adapting them to a new core later will be trivial, and needed anyway
<cat1>
mnemoc: true, but i simply hate looking back and cannot do much about this :)
<cat1>
mnemoc: but again, the things that are currently broken are rather kernel version independant.
<mnemoc>
yes
<mnemoc>
but fixing them earlier in the chain lets more people test it and give feedback
<mnemoc>
the usb drivers desperately need to get decoupled from android
<mnemoc>
and the farther you go, the harder it will be
<cat1>
mnemoc: usb framework is big pain as such, regardless android.
<mnemoc>
:)
<mnemoc>
at least we know that when using android, in 3.0 it works
<mnemoc>
in 3.4 doesn't
<mnemoc>
in 3.6... :)
<cat1>
so it should not in 3.6
<mnemoc>
so it's better to decouple them in 3.0
<mnemoc>
and then forward a well tested android-less usb driver
<cat1>
mnemoc: any good usb specialist around here? ;)
<cat1>
mnemoc: anyway, i need some more inspiration before looking into something boring, like e.g. usb stack.
<cat1>
... and messy as well/hell
<mnemoc>
you can dive into pinctrl or the clock common framework if you like, which are the entry points to the future
ibot has joined #arm-netbook
<cat1>
mnemoc: pinctrl is yours, remember? ;P
<mnemoc>
cat1: problem is that I already have 2 full time jobs :<
<cat1>
oh. lucky person!
<mnemoc>
not by choice, imposed by the level of spending of my women :|
<cat1>
mnemoc: this does not require any explanation -- this is by default! :D
<mnemoc>
:D
<mnemoc>
you can also dive at other drivers, nand maybe? or the PMU?
<mnemoc>
they all need tons of love
Yakuzzi has quit [Remote host closed the connection]
Yakuzzi has joined #arm-netbook
<cat1>
mnemoc: virtually everything in a10 tree needs love.
<mnemoc>
an xorg EXA driver would be welcomed too... and that's userspace
* cat1
dreams of million euros for free to spent more time on hobbies..
<cat1>
mnemoc: what i think of all this is that we really need to try push core stuff upstream and focus on this mostly. Once it is there, more developers will be attracted.
<cat1>
mnemoc: dreaming of impossible, i know..
<mnemoc>
cat1: in that case, clock common framework?
<cat1>
mnemoc: right
<mnemoc>
cat1: that's new code, so copyright header is all yours, and that helps the CV
Yakuzzi has quit [Remote host closed the connection]
Yakuzzi has joined #arm-netbook
<cat1>
mnemoc: in theory yes :)
<mnemoc>
:)
Yakuzzi has quit [Remote host closed the connection]
TomNL has quit [Quit: Quick! Kill your client! Bersirc 2.2 is here! [ http://www.bersirc.org/ - Open Source IRC ]]
Yakuzzi has joined #arm-netbook
QingPei has left #arm-netbook [#arm-netbook]
n6pfk has joined #arm-netbook
n6pfk is now known as mmmm
mmmm is now known as mickey_w
mickey_w is now known as sss
sss is now known as mickie_w
mickie_w is now known as aaa
Yakuzzi has quit [Remote host closed the connection]
aaa has quit [Client Quit]
Yakuzzi has joined #arm-netbook
mikey_w has quit [Remote host closed the connection]
mikey_w has joined #arm-netbook
Yakuzzi has quit [Remote host closed the connection]