<oliv3r>
if (clk_set_rate(ve_moduleclk, pll4clk_rate/v_div)) {
<oliv3r>
so they turn 960000000 into 0.8 + 'arg_rate' i guess
<oliv3r>
really nasty shit
<oliv3r>
ok maybe i typed pll4clk_rate wrong there, it's 96 MHz
<wingrime_>
what do you think about my teory or i have use #ifdef
<oliv3r>
which gets reduced to 96 Hz + 'arg_rate'
<oliv3r>
ok sun4i and sun5i both translate to this:
<oliv3r>
clk_set_rate(ve_moduleclk, 120000000);
<oliv3r>
it's exactly the same for both sun4i and sun5i
<oliv3r>
i do not know where pll4clk_rate is used elsewhere
<oliv3r>
but why they choose to do such crazy math, is beyond me for now
<oliv3r>
and sun6i is even more retarded
<oliv3r>
i think sun6i is underclocked actually
<oliv3r>
ohh wait
<oliv3r>
no nono
<oliv3r>
sun6i overclocks
<wingrime_>
you say that sun4i and sun5i runs on same clock
<wingrime_>
may be it used somewhere else
calris has joined #linux-sunxi
hipboi has joined #linux-sunxi
<calris>
finally have sunxi U-Boot compiling :)
<wingrime_>
oliv3r: OK i send patch to unify cedarx
<wingrime_>
oliv3r: using sun4i code
<oliv3r>
wingrime_: unless pll4clk_rate is used somewhere else in the same code of course ;)
<oliv3r>
i'll check mailing list for your patch :)
<oliv3r>
btw, sun6i overclocks VE
<oliv3r>
it's 960/6
<oliv3r>
160 MHz
<oliv3r>
instead of 120 MHz
<oliv3r>
but for the IOCTL_SET_VE_FREQ
<oliv3r>
it does something different (on sun6i)
<wingrime_>
oliv3r: I do it only for sun45
<oliv3r>
sun7i is also 720/6
<oliv3r>
but they didn't even change the comment
<oliv3r>
chinese math, 720/6 = 160
<oliv3r>
wingrime_: but make sure to checkout :IOCTL_SET_VE_FREQ
<oliv3r>
they do some things there on sun6i and sun7i
<wingrime_>
oliv3r: VE_FREG normal in sun4i
<oliv3r>
i see, sun7i is same
<oliv3r>
sun6i is really different
<oliv3r>
so sun6i will need quite some 'ifdef's
<oliv3r>
lemme check that ioctl on sun5i
<wingrime_>
oliv3r: I can support sun6i when I have this HW
<wingrime_>
oliv3r: It will better for AW to send me it for free :)))
<oliv3r>
oh in sun5i it's all commented out
<oliv3r>
wingrime_: you don't want sun6i; sun7i is better :p
<oliv3r>
wingrime_: i wonder why IOCTL_SET_VE_FREQ is NOP in sun5i
<oliv3r>
if we know what usese that ioctl, it can be tested what it does for sun5i and maybe re-enable it
<wingrime_>
oliv3r: we need one version of this in top-prior
<oliv3r>
wingrime_: yep :)
<wingrime_>
oliv3r: cedarx simple comparea usb hell
<oliv3r>
lol yeah
<oliv3r>
i was looing at the sun4i_vibrator driver
<oliv3r>
but there is no sun5 sun6 or sun7 vibrator driver
<oliv3r>
so looks like it's allready unified, but needs a unified name :)
<wingrime_>
oliv3r: sunxi avs broken
<wingrime_>
sun4i_avs.c for older kernels
<Turl>
hi wingrime_
<Turl>
wingrime_: I played a bit with SS but can't get it to work for MD5
<Turl>
wingrime_: I got PRNG working though
hansg has joined #linux-sunxi
<oliv3r>
PRNG is maybe just a small step, but it's still a good step
<wingrime_>
Turl: HW random cool thing
<wingrime_>
Turl: it also can get some performance
<oliv3r>
Turl: enlighten me though; could I in theory, use the crypto engine in two drivers in the kernel? since random is a different driver usualyl in ther kernel then the crypto stuff
<oliv3r>
isn't there a tool to check if random is really random?
<oliv3r>
just to make sure their randomizer isn't broken :)
<Turl>
oliv3r: idk, I'm not an expert on random nor crypto :P
<Turl>
just playing with registers with mmap+C
<Turl>
mripard_: ping
<oliv3r>
Turl: afaik, there are some tools to check if something is truly random
<oliv3r>
Turl: to verifiy if a random generate isn't 'fake' random; kinda important for crypto
<Turl>
I'll upload the code I worked on later so you guys can play with it
<wingrime_>
oliv3r: you can help me If you test my last unification patches
<wingrime_>
oliv3r: I send cedar unification
<oliv3r>
i have never used cedarX; so wouldn't know how to test on A10 :)
<oliv3r>
i guess if I can install vlc-cedarX on linaro, i can test 'normal' cedarX and then your patches
<oliv3r>
but won't be home till tonight :)
<wingrime_>
oliv3r: at-least I failed with vlc on a13
<oliv3r>
i'll first h ave to set up a test enviroment with vlc + a10 + cedar
<oliv3r>
or do we have mplayer + a10?
<wingrime_>
nop
<oliv3r>
even easier, do we have pre-compiled binaries?
<oliv3r>
if anybody could point me to a binary vlc + cedarX i'll test wingrime_'
<oliv3r>
s unitication patch
<mripard_>
Turl: don't know, never asked them
<mripard_>
but I wanted to do that driver, it looked fun :)
<oliv3r>
does anybody know if the RTC used inside the A10/A13 is a Philips PCF8563?
<oliv3r>
or has aw simply polluted their header with some copy/paste?
<mripard_>
Turl: anyway, I can ask them
rellla2 has joined #linux-sunxi
<oliv3r>
ohh, sun4i has its own built in timer, sun5i uses the pcf8563
<ssvb>
Turl: http://en.wikipedia.org/wiki/TestU01 can be used to check whether the random number generator is good enough for scientific simulations (cryptographic purposes are a bit different thing and require more strict verification)
<wingrime_>
mrioard: also ask them ,"Have USB controller hardware any differences in a10-13"
rellla has quit [Ping timeout: 245 seconds]
<Turl>
mripard_: the register description on A13 is pretty complete but unfortunately it doesn't help much without an explanation on how to operate it
<oliv3r>
many questions!
<oliv3r>
a13 doc is a little more complete then a10; the combination is best
<Turl>
the PRNG was easy to get going, you just enable it and it feeds you with numbers
<Turl>
ssvb: I'll give it a try, thanks
<oliv3r>
wingrime_: what A13 based device do you have?
<mripard_>
wingrime_: you should really learn to use the tab shortcut to do completion on the IRC nicks
<mripard_>
Turl: and no code to help you I guess?
<hipboi>
mripard_, yes, tab works
<hipboi>
mripard_, i just know it
<Turl>
mripard_: no driver that I'm aware of
<oliv3r>
i wonder if the A13 simple has no RTC and uses it via i2c seperatly
<Turl>
hipboi: do you happen to know anything about the security system on sunxi?
<hipboi>
Turl, what security system
wingrime_ has quit [Read error: Connection reset by peer]
<Turl>
hipboi: hashing and encryption engine
<hipboi>
oliv3r, A13 has no rtc
<oliv3r>
hipboi: ah, that's why rtc-sun5i.c is a raped version of rtc-pcf8563.c
<oliv3r>
ok, no need to ocompare those two then
<hipboi>
Turl, there seems to be a driver
<hipboi>
Turl, but i am not sue if we are talking about the same thing
wingrime has joined #linux-sunxi
<Turl>
hipboi: random number generator + MD5/SHA1 + DES, 3DES, etc
<ssvb>
Turl: just compile and install this TestU01 library and check 'examples/ex7.c', it shows how to test a custom random number generator function (replace 'xorshift' function with the calls to get uint32_t values from the hardware PRNG)
<oliv3r>
but there's also 'arm-trustzone'
<Turl>
arm trustzone is a different thing
<calris>
hipboi: Is there any detailed documentation on the format of the boot0 / u-boot-spl header?
<hipboi>
calris, no
<oliv3r>
calris: what are you after?
<calris>
hipboi: I'm looking at the U-Boot code, and it does not seem that much of it is used apart from magic, size and checksim
<oliv3r>
assuming the axp202 is similar, it's in english, the axp209 is chinese only
ganbold_ has joined #linux-sunxi
<oliv3r>
wingrime: i don't think there's a limit
<oliv3r>
there's nothing about maximum capacity in the datasheet
<oliv3r>
so as long as you setup the % parameters, you can hook up a car battery :p
<wingrime>
oliv3r: it depends charge current
<wingrime>
mnemoc: are here?
<oliv3r>
wingrime: well it will just take really long to charge :p
<oliv3r>
charge current is defined in the datasheet
<wingrime>
oliv3r: why ethernet driver not using dma
<oliv3r>
wingrime: i have no idea, but i think because it's a buggy pos :p
<oliv3r>
but mripard_ and stephano where working on it (see mailining effort wiki page)
<oliv3r>
does anybody know btw, if I have a tablet (LCD output) can I still use HDMI output for AUDIO? (I did see alsa mixer for hdmi, so my initial guess is 'yes')
<wingrime>
olivr: alsa works
torindel has joined #linux-sunxi
<oliv3r>
yeah, but i don't want video output to hdmi, only audio, is that possible?
<oliv3r>
so vidoe = LCD, audio = hdmi
<oliv3r>
i think it should be enabled and active by default
<wingrime>
olivr: you have analog audio
<oliv3r>
yeah
<wingrime>
olivr: what problem connect some speakers
<oliv3r>
but if i do mplayer -au alsa:hw2 it should go to hdmi
<oliv3r>
wingrime: sun4i/hdmiaudio unification :p
<oliv3r>
wingrime: i need to test if it works :p
<oliv3r>
duh
<oliv3r>
silly wingrime
<wingrime>
mplayer can play audio to tablet speakers
<wingrime>
mplayer you simply need config it right
<oliv3r>
what output is connected by default?
<oliv3r>
i2s?
<wingrime>
none
<oliv3r>
what output is the analog output on a tablet?
<wingrime>
whait
<wingrime>
I need boot it)))
<oliv3r>
ok :)
<oliv3r>
i'll check the datasheet
<wingrime>
wait
<oliv3r>
page 242 of A13 pdf
<oliv3r>
LRADC is different too Audio Codec
<oliv3r>
so if the analog bit is LRADC, then it's two seperate sound 'cards
<oliv3r>
6bit ADC only :(
<oliv3r>
LRADC is only for volume buttons?
<wingrime>
try mplayer -ao alsa:device=hw=0.0
<oliv3r>
well it just does 2 buttons :)
<wingrime>
yep LRADC is volume buttons
<oliv3r>
wingrime: i don't have my tablet at $work$ with me :)
<wingrime>
I configured dmix
<oliv3r>
lradc is just a 'digital potentiometer'
<oliv3r>
wingrime: can you check
<wingrime>
lradc: is low resolution analog to digital converter
<wingrime>
buttons have resistive matrix
<oliv3r>
wingrime: can you check with alsamixer how -c 0 and -c 1 is 'named'
<oliv3r>
wingrime: yeah lradc turns up/down button into a reference voltage or something, u don't know electronics much :p
<torindel>
oliv3r: as for: configure lcd and hdmi video outputs (even if hdmi is separate framebuffer and only shows black screen) and then just use mplayer -ao -vo with correct devices (if theres no video output on hdmi most tv's wont like you)
<oliv3r>
but i think 'digital potentiometer' sounds close enough for us non ee-engineers to figure out
<wingrime>
c0 for me sun5i-CODEC
<oliv3r>
torindel: my tv is very old; so i hope it'll just work; otherwise i'll setup a script.bin with hdmi for testing ;)
<torindel>
oliv3r: then most probably you'll need hdmi video enabled ^^
<wingrime>
c1 for me sun5i-sndhdmi
<oliv3r>
torindel: feck :S :p
<oliv3r>
wingrime: do you have -c 2; -c 3 or anything?
<torindel>
oliv3r: just make it separate empty framebuffer ^^
<torindel>
you'll have dualscreen for free then
<oliv3r>
wingrime: then SND_SUN4I_SOC_CODEC is the 'analog' output on the chip; SND_SUN4I_SOC_HDMIAUDIO sun4i-sndhdmi
<oliv3r>
torindel: i'll 'try' :p
<oliv3r>
torindel: my script.bin-fu is low
<wingrime>
olive3r : I don't know why a13 have hdmiaudio in kernel
<torindel>
wingrime: esp since a13 doesnt have hdmi in chip ^^
<oliv3r>
maybe it does have the hdmi audio pin ;)
<oliv3r>
the Die has hdmi i'm sure, they just didn't route the pins to the outside
<torindel>
dont think so
<oliv3r>
you don't think it's binned A10's?
<torindel>
they stripped sata and hdmi parts
<oliv3r>
having a second production run of an extremly similar die is quite expensive, just not bringing out the pins is much cheaper
<oliv3r>
'broken hdmi'? A13; broken sata?; a13
<wingrime>
oliv3r: that tablet extrimly expensive 2500 rub in local store
<wingrime>
even 2200
<oliv3r>
wingrime: what tablet?
<oliv3r>
well they've implemented the SUN5I hdmi audio driver :)
<oliv3r>
anyway, i'm gonna bend my mind over audio unification, see what i find
<oliv3r>
since the butchering increases numbering :)
<oliv3r>
which why A20 is better then A31 :p
<oliv3r>
and A40 will be quad :p
<torindel>
a31 is quad
<oliv3r>
if they ever bring out a A40
<oliv3r>
a31 is crap
<oliv3r>
:)
<oliv3r>
i'm supprised they didn't name it A40; appearantly they didn't feel it as a true A40 either :)
<torindel>
hardware wise a31 is better, more cores, faster (2-channel) mem controller, 2-channel nand controller, more cores of gpu (lets forget about driver for now ;p)
<wingrime>
crap is that A7 cortex
<torindel>
a20 is a7 coretex also
<wingrime>
if it was A9 it will be win
<mripard_>
A7 are more or less equivalent to A9 in terms of performance, only a lot more power efficient
<wingrime>
only 5 hours with 9000 mAh bat I remember
<wingrime>
sorry 8000 mAh
<wingrime>
240$
<wingrime>
too expensive for mere china tablet
<torindel>
mripard_: looking on arm website a7 is about 20% more DMIPS on max freqs on dualcore ^^
<wingrime>
a8 2 DMIPS a7 1.9 DMIPS
<torindel>
wingrime: a9 mpcore max freq 1ghz, a7 mpcore max freq 1.5ghz
<torindel>
wingrime: plus you can mix a7 with a15 if you want more power ^^
<wingrime>
torindel: everywhere lie about than a10 have 1.5 ghz
<torindel>
wingrime: a8 have max recomended freq 1ghz acording to arm
<wingrime>
torindel: I can mix when I get arm license, verilog files, semiconductor factory at backyard
<torindel>
and 1.5 on a7
<torindel>
wingrime: and as for mixing a7 with a15 you got seamless migration from a7 to a15 core and vice versa at runtime
<torindel>
(powersaving)
<wingrime>
torindel: samsung have better soc than AW
<torindel>
wingrime: so far we're talking about core types not end user product ^^
<torindel>
wingrime: and if youre talking about samsung in chromebook etc thats a15 :P
vicenteH has quit [Ping timeout: 240 seconds]
<oliv3r>
torindel: isn't the A20 also dual channel memory controlle rand dual channel nand controller?
<oliv3r>
if not, i wouldn't be supprised if A40 is quad a7 with dual controllers and mali 400 or 600? one can drea :)
<libv>
mali-450 more likely thna t6xx
<oliv3r>
hey libv :)
<libv>
mali-450 == up to 2GPs and 8PPs
<libv>
so double mali-400
<libv>
and double the performance
<oliv3r>
just tell me there will be an A40 with mali-450 :)
<libv>
i wouldn't know
<oliv3r>
:(
<libv>
but i am wishing for it too
<oliv3r>
:)
<libv>
chances are it will be a mali-400 though
<libv>
75% mali-400-MP4
<oliv3r>
so it would be similar to a A20
<libv>
which is double the speed of the A20 gpu, in real world terms (double the PPs)
<torindel>
lets add quad core coretex a15 + 1x a7 to the wish list ^^
<oliv3r>
wouldn't that kill power efficiency?
<libv>
once T624 is shipping, i think ARM will let mali-450 be implemented
<torindel>
oliv3r: nope as you would enable a15 only when you need power and stick to a7 when not
<libv>
mali-450 would make the t604 look way too poor
<oliv3r>
libv: nobody is allowed to do a mali-450 yet?
<oliv3r>
torindel: i'd expect 2x a7 and 4x a15
<libv>
i do not know
<libv>
but i find it logical
<oliv3r>
libv: well you say 'let be implemented'
<libv>
oliv3r: mali-450 is mostly about fixing the management engine and the mmu, and then throwing in double the silicon and then fixing power management/clocking issues
<libv>
it was announced a year or so ago
<libv>
we should start hearing rumours about chips going to implement it 6 months from now
<libv>
which we don't
<libv>
and we know that the t604 was a disappointment
<libv>
which is why samsung now went pvr for a bit, and ARM quickly but not too noisily announced the t624
<libv>
so... chances are that mali-450 would be eating t604s lunch
<libv>
and that arm is stalling it
<libv>
"stalling" could also be because more effort is being spent on getting t62x good
<libv>
since we haven't heard anything real on allwinner a40... who knows
<libv>
they might even go vivante or, worse, pvr again
<oliv3r>
libv: ah no chips exist with it yet then
<bsdfox_>
anyone happen to have experience with the i2c-sunxi driver? I'm getting errors on writes with 16 bit (15?) addressing when debug isn't enabled but everything works with debugging enabled though at a much slower rate
<libv>
oliv3r: none have been announced or rumoured
<oliv3r>
libv: well 'someone here' said that AW wouldn't do pvr anymore
<libv>
i sure hope so
<libv>
mali-400MP4 would be a good companion for a quad A7
<libv>
mali-450MP2x8 or whatever it would be called, would be even better
<libv>
but wait and see
ZaEarl has joined #linux-sunxi
<libv>
i expect that A40 might happen before the T624 is released, so i guess it will be mali-400
<libv>
all speculation though, wait and see what really happens
<libv>
it might just be that the so far rumoured a40 is simply the a31
<oliv3r>
libv: well lets first get the A20 in our hands
<hipboi>
oliv3r, find out what?
<libv>
oliv3r: indeed
shineworld has quit [Quit: Leaving]
<oliv3r>
hipboi: A40, will that be with mali again?
<hipboi>
:O
<hipboi>
not sure what A40 will be
<hipboi>
aw1639 is the name for big little chip
<hipboi>
aw1633 for A31
<oliv3r>
so the new AW chip will be A7 + A15 design
<hipboi>
aw1651 for A20
<oliv3r>
and A10 was?
<hipboi>
aw1623
<oliv3r>
strange naming :)
<oliv3r>
numbering really
<hipboi>
A13/A12 aw1625
<oliv3r>
A12 = A10s?
<hipboi>
yes
<oliv3r>
I know the A13 usermanual accidentally is called A12 Usermanual
<hipboi>
the same
<oliv3r>
lol; we where just discussing how unfortunate the A10s name was
<oliv3r>
hipboi: have you gotten any news on Cubieboard A20?
<hipboi>
A20 is not stable now
<hipboi>
not suiteable for volume production
<hipboi>
even A31 is not
<oliv3r>
so a few more months?
<hipboi>
2 to 3 months, i think
<oliv3r>
so around summertime; Guess its time to be patient
<oliv3r>
now i regret not getting an A10 cubieboard/mele A1000g
<oliv3r>
but now i'll just wait :)
<hipboi>
the schematic of cubie a31 will be done this week
<hipboi>
the big problem of a31 is the slow dram speed
<libv>
hipboi: aw :(
<libv>
hipboi: why not an a20 cubie?
<libv>
most of the people i talk to want sata on this device
<hipboi>
there will be
<hipboi>
yes, sata + gmac
<libv>
and i do not have a hard time convincing them of the evils of pvr :)
<hipboi>
many people want
<oliv3r>
hipboi: slow dram speed? torindel was saying how 'fast' its memory controllerw as (dual channel)
<libv>
if you do not mind me asking in public, how is the cubieboard selling atm?
<hipboi>
around 6 to 7k
<libv>
hipboi: seems like there is a supply issue mostly, any that you produce seem to sell out immediately
<hipboi>
yes
<libv>
your original kickstarter goal was what, 500 or a 1000?
<hipboi>
1500
<libv>
ah, still "not too shabby" though :)
<hipboi>
oliv3r, it's dual channel, and 64 bit
<oliv3r>
hipboi: but slow :p
<hipboi>
oliv3r, but it can not run higher
<oliv3r>
hipboi: anyway, i'll get one or two A20 cubieboards when out ;)
<hipboi>
oliv3r, slow dram cause the slow gpu
<oliv3r>
hipboi: dram clock speed, you use 480 MHz on A10; about the max for A10, all the slower ones, that limitted by PCB routing? Can't be the used chips
<hipboi>
it's limited by pcb routing and the chip
<hipboi>
the system will die if the dram is high on a31
<hipboi>
not limited by the pcb routing
<hipboi>
on cubieboard, the dram can run at 520M
<hipboi>
stable
<oliv3r>
hipboi: oh really
<oliv3r>
so 'random A10 device' should be able to reach that aswell?
<hipboi>
of course not
<oliv3r>
if the dram routing is done properly
<libv>
well... the mali-400MP1 on the A10 is the main limiting factor. There was improvement with bumping from 360MHz to 480MHz, but iirc, it was not too significant, less than a percent
<libv>
on running q3a timedemo
<libv>
but it was stable on the A7HD, and it still runs its ram at frequency
<oliv3r>
my tablet appears to be stable at 480 aswell
<oliv3r>
i should try 520 MHz :p
rz2k_ has quit []
<oliv3r>
hipboi: anyway, as soon as you have more info on A40 and cubieboard A20; don't be affraid to share :p
<hipboi>
of course
<hipboi>
i think the first a20 cubies will be sent to people here
<hipboi>
for free
<libv>
lima should just work on a20 when i have (finally) ported it to run on exynos with r3p2 drivers, btw
<oliv3r>
7 more minutes before hometime; lets see if i can unify sun4i-audio before then
LeCare has joined #linux-sunxi
<libv>
sunxi-mali might need to get new binaries, and the version and test utilities need to be updated as ARM managed to even shift the versioning ioctl
<libv>
if r3p2 or newer is used in the kernel
<hipboi>
new binaries is on the way
<oliv3r>
cedar-openmax?
<hipboi>
no clue...
<oliv3r>
:(
shineworld has joined #linux-sunxi
torqu3e has joined #linux-sunxi
<oliv3r>
hoemtime
<oliv3r>
see ya all later
<rellla>
on the way implements that it was already sent \o/
ganbold_ has quit [Remote host closed the connection]
<wingrime>
hansg has quit [Remote host closed the connection]
ZaEarl has quit [Ping timeout: 256 seconds]
hipboi has quit [Remote host closed the connection]
<mnemoc>
wingrime: pong
<wingrime>
mnemoc: patches )))
n01 has quit [Quit: leaving]
<mnemoc>
wingrime: what's the oldest I'm missing from you?
eebrah has joined #linux-sunxi
vinifm has quit [Remote host closed the connection]
shineworld has quit [Quit: Leaving]
<wingrime>
sun5i:usb: fix usb resume on a13 devices
<wingrime>
axp_power: change battery type from LiFe to most common LiIon
<wingrime>
sunxi:i2c: Don't print initial register state on boot
<techn_>
hmm.. I dont like those fex patch patches :/
<techn_>
makes things complicated.. for submitting patches and managing different fexes
[E3] is now known as Epsylon3
Epsylon3 has quit [Changing host]
Epsylon3 has joined #linux-sunxi
<bsdfox_>
wingrime, you're working with i2c? Have you had any issues when debugging is disabled?
<bsdfox_>
everything seems to work properly when I've got I2C_DEBUG_CORE, I2C_DEBUG_ALGO, and I2C_DEBUG_BUS enabled but I have lots of misc issues when they're not
<oliv3r>
techn_: well there's a lots of variants on a single board, the boards are all identical; they only have different batteries, different tochscreens or different camera's; what's the best way to handle it?
<techn_>
oliv3r: I think current way is easy.. We have to do ftd eventually
n01_ has joined #linux-sunxi
<techn_>
which will make thing clear.. but thats my humble opinnion
<oliv3r>
techn_: so i should duplicate everything (u-boot etc) just because I have different battery/touchscreen?
<techn_>
oliv3r: how you can know which config you have use if your device is not specified precisely
ibrah has joined #linux-sunxi
<techn_>
and it's impossiple to compare your stock config against patches
<techn_>
ofcourse better wiki for devices would help :p
eebrah has quit [Ping timeout: 245 seconds]
<techn_>
how many different boards we have for a10 and a13?
<techn_>
oh.. and even if board is same ram chips could be different
<oliv3r>
techn_: ideally, you'd have a database with brand - ts, board, etc
<oliv3r>
but yes
<oliv3r>
techn_: it's never easy to handle it properly
<oliv3r>
but once we have fdt this may get a little better
<oliv3r>
and then also, a lot of drivers rely on script.bin for things they shouldn't
<oliv3r>
did the kernel change __devinit to __init?
<techn_>
hmm.. maybe u-boot boards.cfg could support combining of devices
<Turl>
oliv3r: __devinit got killed on 3.8 or so iirc
<oliv3r>
but whatever we do for now; is al intermediate
<oliv3r>
:)
<oliv3r>
Turl: so replace __devinit with __init?
<oliv3r>
Turl: funny that for sun4i they used __devinit; and for sun5i the yuse __init :)
<Turl>
I suppose so
<oliv3r>
ok then i will replace __devinit with __init
<oliv3r>
turl: so if __devinit got killed; I assume __devexit took the same plunge and got replaced with __exit?
<oliv3r>
these people code like the best :)
<Turl>
I think so too
<oliv3r>
on one bit, they did use __init in both version
<Turl>
and one of the __devsomething_p macros too
<oliv3r>
on the other bit, they 'upgraded' the __devinit to __init; and finally, they didn't bother with __devexit -> __exit
<mnemoc>
techn_: suggestions to support .fex files variants instead of patches?
<Turl>
mnemoc: #include + cpp :D
<bsdfox_>
oliv3r, they're all winners
<oliv3r>
Turl: could you be a little more specific so I can grep fro it?
<mnemoc>
Turl: what? extending a legacy format???
<oliv3r>
bsdfox_: I'll have to check the datasheet, but they even managed to change a comment from 'enable' to disable' yet the function does exactly the same
<Turl>
oliv3r: __devexit_p
<Turl>
mnemoc: patch would be an extension too
<mnemoc>
Turl: no, the result would be a plain .fex
<mnemoc>
cp + patch
<oliv3r>
i'd prefer autoconf to handle those things if anything :)
<mnemoc>
.oO(autoconf?)p
<techn_>
mnemoc: what is problem with current ?
<mnemoc>
Turl: there is nothing invented in using a patch...
<mnemoc>
techn_: duplication between variants
<Turl>
mnemoc: there's nothing invented on running cpp on a file either :p
<techn_>
I dont see it duplication.. they are just copies from devices.. only duplication I see is in u-boot
<mnemoc>
Turl: #include won't let you make a 512MB variant of a 1GB board
<mnemoc>
techn_: I would like u-boot to load the `struct dram_para` from a dd-able place
<oliv3r>
with patch, we simply pass 'board=something variant=someothervariant'
<Turl>
anyway, I don't see it as duplication either, adding patch or anything else would be burdensome imo
<oliv3r>
but i think initially reading some memory location is good
<mnemoc>
:o
<oliv3r>
oh (and I should have asked hipboi)
<oliv3r>
has anybody tried using or writing to SRAM B?
<oliv3r>
we talked a little bit about SPL
<oliv3r>
and reasoned that, maybe it is posisble to hijack SRAM B (64k)
<mnemoc>
Turl: yes, I agree that (regardless the method) the extra complexity is hard to justify
<oliv3r>
so that instead of 20k for SPL, it would be 84k of sram possibly
<oliv3r>
the datasheet just lists SRAM B as 'secure' which could possibly mean, that is' ment for use of ARM trustzone; but SPL may be able to hijack it
<oliv3r>
or 'borrow' it rather
<mnemoc>
oliv3r: if that was possible, why would allwinner make the boot0 -> boot1 -> whatever.axf chain?
<mnemoc>
everything for an splash screen?
<oliv3r>
mnemoc: yes
<oliv3r>
:p
<mnemoc>
:)
<oliv3r>
mnemoc: maybe arm says 'we need 64k for trustzone that you cannot use'
<jelly-home>
Turl: you implied you managed to do anything with the "security system" last night ie. make PRNG work?
<oliv3r>
and they follow appropiatly
<oliv3r>
jelly-home: turl got prng going :)
<oliv3r>
jelly-home: but md5 didn't work yet
<jelly-home>
nice, /me interested in AES and RNG (not P)
<Turl>
jelly-home: PRNG was easy to get going, you just enable it and then read the infinite stream on the tx fifo
<jelly-home>
and the seed?
<Turl>
I tried md5, enabled the md5 mode, fed it stuff on the fifo but it doesn't hash, or hashes to something that's not the actual hash, and is overall not working
<Turl>
jelly-home: yeah you can seed it, I just didn't for sake of testing
<Turl>
jelly-home: do you want to give AES a try and see if you get it going?
<jelly-home>
you poked at the mmio regs from userspace or? I'm clueless about how hw access works on Linux.
<Turl>
yeah, via /dev/mem + mmap
<Turl>
you map the reg area
<mnemoc>
and ioctl() for everything that's not mem
<Turl>
and then poke
<jelly-home>
good, that's pretty much the same way it worked on Commodore 64 ;-)
<Turl>
jelly-home: if you want to give it a go I'll upload my POC code somewhere now
<jelly-home>
Turl: sure, I don't have a lot of time at hand but perhaps it will magically start working on its own
n01_ has quit [Quit: leaving]
<techn_>
hnn
<techn_>
did hramrack test that nand compat stuff? :(
Wetomelo has joined #linux-sunxi
<techn_>
oliv3r: this could be the reason you didn't manage to boot latest kernel with android :/
<techn_>
root=/dev/nandd doesnt work.. you must use root=/dev/nand{number}
<mnemoc>
btw, there is new stock of cubieboards if someone still needs one
<mnemoc>
techn_: that's a CONFIG_
<techn_>
mnemoc: it wont work
<mnemoc>
ow
<mnemoc>
that's bad
<techn_>
sure it changes /dev/nand{number} to /dev/nand{letter}
<Wetomelo>
Ho there is a module compiled ( maybe in a hwpack) for PL2303 or FTDI chips for a MiniX ?
<mnemoc>
Wetomelo: just compile your own kernel ;-)
<techn_>
but kernel's rootfs init doesnt care about those.. it uses device more directly
<Wetomelo>
i have an sdcard system running, stripped
<Wetomelo>
maybe i can reuse the rootfs
<Wetomelo>
and hwpack
ibrah has quit [Ping timeout: 255 seconds]
<oliv3r>
techn_: i tried stage and non stage 3.0 and 3.4 kernels (i think)
<Wetomelo>
i have one more silly question
<oliv3r>
techn_: can I pass my root=/dev/nand4 in --cmdline?
<Wetomelo>
how persistence works without casper?
<oliv3r>
techn_: though I think the kernel actually fails to load
<mnemoc>
oliv3r: are you in kernel testing mood? can you try soc-detect and give me the first kernel log? :)
<techn_>
oliv3r: screen goes black right before boot should change to rootfs's init
<mnemoc>
oliv3r: wip/sunxi-3.*/soc-detect in my github
<Turl>
Wetomelo: I think rm's builds have all those things enabled
<oliv3r>
techn_: are you 100% sure kernel doesn't clear the boot.axf android.bmp until rootfs gets loaded? (I don't belive it, because right now, i have the android bmp; clear screen for about 6 seconds, then the android boot animation)
<oliv3r>
mnemoc: ok i'll clone your kernel
<mnemoc>
oliv3r: it's cheaper if you add it as an extra remote of a current working tree
<mnemoc>
it's a fat repo... including all lichee/*-dev branches
<oliv3r>
mnemoc: oh god your making me do hard stuff
<xenoxaos>
or pull the tarball
<oliv3r>
i'll do that
<techn_>
oliv3r: screen is cleared just before rootfs.. ~ less than 1 second before.. I'm sure of that since I dont have rootfs loaded and screen is cleared :)
<Wetomelo>
Because the hwpack script only enable internal things
<oliv3r>
techn_: so you have the boot logo up for ... about 6-10 seconds?
<techn_>
oliv3r: I think it's fbcon which does the clearing
<Wetomelo>
all the hardware of the MiniX works OK but doesn't have modules or kernel suported ftdi chips
<oliv3r>
techn_: well i'm willing to try, if you tell me that i can pass it via '--cmdline' to mkbootimg :)
<oliv3r>
cause normally you don't pass root i found
<techn_>
oliv3r: about u-boots kernel parameter.. I'm not sure where its located on nand :/
<techn_>
and I dont have device which boots currently ;)
<techn_>
trying to figure out how to get NAND_COMPAT working :p
<mnemoc>
is it possible to get root=/dev/nandd working again?
<mnemoc>
that's a serious compatibility flaw...
<oliv3r>
i can't check right now, but how does the boot1 know it's nandd and not nand...x
<mnemoc>
boot1 doesn't work on linux ;-)
<mnemoc>
it uses the NFC directly
<oliv3r>
mnemoc: building
<mnemoc>
oliv3r: in theory you should see a line telling "sunxi: allwinner A10 revision C detected" before, or immediatelly after sunxi: BROM ver: ....
<mnemoc>
for some weird reason techn_ doesn't see it :<
<mnemoc>
and I can't test currently :( ... I don't even have a desk atm... everything packed
<techn_>
mnemoc: I'm using a13
<mnemoc>
techn_: code should work for A13 too... that
<oliv3r>
i'll pull out my a10 soon
<mnemoc>
's actually the point of soc-detect
<mnemoc>
sunxi_is_a13() and sunxi_is_a10s()
<mnemoc>
but if it's not greeting, something is going wrong
<techn_>
mnemoc: I commented if (likely(ver)) out.. didn't help :p
<mnemoc>
i don't get it :<
<mnemoc>
it must greet... or at least print an error
<mnemoc>
but silence is disturbing
<oliv3r>
i need a few mins
<techn_>
mnemoc: function is declared as const but not defined as it?
<mnemoc>
techn_: as long as it's in the .h it should work.... afaik
<techn_>
but anyhow I dont see how const fits there eighter.. it shouldn't access global memory and has no parameters.. so it could be optimized out
<mnemoc>
techn_: afaik a const function is a function which return value can be optimized by the compiler
<mnemoc>
techn_: and so avoid calling it again and again in a if (sunxi_is_foo()) { ...} else if (....) thing
<mnemoc>
but anyhow, the function returns the precalculated value in all except the first call
<mnemoc>
but if it's not greeting...... /me cries
<oliv3r>
it seems to be booting
* mnemoc
should just try to find his cubieboard... but his wife would kill him
<mnemoc>
it should be print immediatelly after BROM Ver
paulk-desktop has quit [Quit: Ex-Chat]
<oliv3r>
mnemoc: sure
<mnemoc>
techn_: soc-detect actually worked on oliv3r's A10. message is print first time in line 57 of http://paste.debian.net/244611/. immediatelly beofre DMA's init
<techn_>
mnemoc: no chuch print for me
<mnemoc>
uhm
<mnemoc>
the disp driver checks for soc version... you should see something :<
<mnemoc>
narf
<techn_>
tried to search "sunxi: Allwinner"
<mnemoc>
search sunxi alone
<mnemoc>
sunxi: ... thre aren't many drivers prefixing that way
<mnemoc>
techn_: you should also see soc-detect related stuff if you try gpio eint :)
<techn_>
mnemoc: only "sunxi: BROM Ver: 1100 1100 1625"
<mnemoc>
but I suppose you don't have much use for that on your a13 tablet
<calris>
Not overly concerned with it being in Linus' tree - just wondering where real-world functionality is at
<Turl>
calris: 3 and 3.4 trees on linux-sunxi
<mnemoc>
in the mean time we can keep unifying, refactoring, cleaning, fixing, ...
<calris>
Has there been any work done on implementing FDT support for the sunxi specific drivers?
<mnemoc>
calris: mainlined code is FDTed
<Turl>
the aw code uses fex which is kinda sorta like fdt
<techn_>
next I was thinking to make hdmi decoder part for DRM/KMS driver.. connector is almost movable to there
* mnemoc
likes the fex FAR more than FDT :p
<Turl>
fex is ugly
<techn_>
but connector is the easiest :p
<Turl>
reminds me of win31 and DOS
<calris>
FDT is standard :)
<mnemoc>
Turl: fex *api* or format?
chujalt has joined #linux-sunxi
<Turl>
mnemoc: format
<Turl>
I don't care about the api, they're both implemented and work okay :P
<mnemoc>
Turl: fex can be parsed in SPL, FDT isn't
<mnemoc>
fat cow
<mnemoc>
but sure, in a multiplatform world the complexity of FDT is needed
<calris>
mnemoc: I'm going to start work on that soon
<Turl>
fex has no hierarchy
<Turl>
it's.. ini
<calris>
mnemoc: I've got my build tools and repo set up - time to slice and dice :)
<mnemoc>
calris: the 3.4 tree is NOT inteded for FDT
<calris>
mnemoc: That's why I was asking about the mainlining effort
<mnemoc>
calris: it's intended for unification and refactoring, and real world usage
<mnemoc>
calris: ah, cool :)
<calris>
mnemoc: First pass will be to get filesystem and script.bin support in FDT
<calris>
mnemoc: Then get PoC for FDT ready for mainline
<mnemoc>
calris: you mean u-boot-spl?
<calris>
mnemoc: Yes
<mnemoc>
why not simply dd the binary `struct dram_para` ?
<mnemoc>
that would give you a board neutral spl
<mnemoc>
fexc can be used to read the script.bin and generate the dd-able chunk
<calris>
mnemoc: Because it makes life difficult :P
<techn_>
or get that dram info from somewhere on device :/
<techn_>
ot should be there
<techn_>
it
<calris>
I want to be able to edit via a file in /boot
<mnemoc>
techn_: that would mean reading boot0's header
<mnemoc>
techn_: which is even more complex :<
<mnemoc>
calris: edit the .fex and run an script :p
* calris
rolls eyes
<techn_>
mnemoc: do you know address of boot0 header?
<mnemoc>
a sort of `visudo` but editing script.bin would do it nicely
<mnemoc>
techn_: first block of the raw nand
<mnemoc>
techn_: but it only works via DMA
<calris>
The idea is to partition the SD card and dd SPL - from there, you should never need to dd ever again - just mount the partition and update the files
<calris>
same should apply to NAND if we ever get a U-Boot driver
<mnemoc>
we have an ugly driver... in the lichee-dev branch
<calris>
mnemoc: NAND can wait - once core is sorted out it should just plug into the SPL build
<mnemoc>
even if it's not perfect a `vifex` would do it nicely
<oliv3r>
mnemoc: hans's patch for sunxi-sound looks really good; i'll test it tomorrow
<mnemoc>
awesome
<mnemoc>
btw, the best way to get me merging stuff fast is by getting an Acked-by
<mnemoc>
specially now that I can't test things myself :<
<oliv3r>
the only thing I dont' get, he didnt rename anything to sunxi
<oliv3r>
it's all sun4i
<oliv3r>
since it's both in use for sun4i and sun5i (same audio 'IP' i guess) shouldn't it be named sun5i?
<Turl>
it should be sun4i since it's the oldest SoC with the IP
<Turl>
at least that's what mripard_ told me today :P
<oliv3r>
so, what does the sunXi stand for? or how shall we unify?
<oliv3r>
so rename unified drivers back to sun4i? :p
<Turl>
sunxi was a nice name when there was only sun4i and sun5i
<Turl>
as they're mostly a simplified version of the other
<mnemoc>
sun7i is also compatbile
<mnemoc>
and most of sun6i still is
<Turl>
sun6i differs considerably on some aspects
<mnemoc>
the core might have changed, but most IPs are the same
<mnemoc>
uart, i2c, spi, ... all that stuff hasn't changed
<oliv3r>
ok in that case, sun*i is a horrible name for any of it
<oliv3r>
:p
<Turl>
so sunxi would be awkward to use when it's sun45i compatible but not sun6i
<oliv3r>
sun457i, but not 6 :)
<oliv3r>
well all these parts have internal names :)
<mnemoc>
in multiplatform they must be made compatible anyway
<oliv3r>
hipboi mentioned it earlier; aw1638 or something is A31
<oliv3r>
so we're not unifying to sunxi anymore?
<Turl>
mnemoc: not really, if they differ a lot you'd have two drivers :)
<mnemoc>
so why a not just using mach-sunxi/soc-a31.c is beyond me
<Turl>
the mach is still sunxi
<Turl>
we're talking about drivers and DT compatible string names
<mnemoc>
oliv3r: that's the number I print from brom ver:
<oliv3r>
mnemoc: ah yeah!
<oliv3r>
i just remember reading somwhere that the mem controller? also has its internal name similar
<mnemoc>
but it's not that easy because A13 and A10S share the same chip id in brom :<
<oliv3r>
it's a messy thing :D
<oliv3r>
so, audio driver should be sun4i
<oliv3r>
because sun5i is the exact same audio
<oliv3r>
and while it makes sense to name it sunxi; we name it sun4i for the FDT parsing later
<mnemoc>
calling sun4i something that will be used by sun5i and sun6i is WRONG
<mnemoc>
imo
<oliv3r>
but mripard_ said today it has to be sun4i! :p
<Turl>
calling it sunxi when it doesn't work on sun7i is wrong too
* mnemoc
glad to not be in that fight
<oliv3r>
Turl: i think it is in sun7i; but not in sun6i :)
<Turl>
whatever, you get my point :)
<mnemoc>
Turl: sunxi-7i-foo
<mnemoc>
vs sunxi-foo
<Turl>
what's the extra i for?
<mnemoc>
don't know ;-)
<Turl>
anyway
<Turl>
keep unifying, I don't mind how you name it as long as it's not SUN9000I
<Turl>
because everyone knows it should be 9001I :P
<oliv3r>
well i personally, find sunxi-foo to be descriptive it says 'all sunXi generations'
<oliv3r>
if there's 1 that's different, there can be a sun6i-foo
<oliv3r>
what if it's only 45 and 6789 get something new (emac vs gmac)
<oliv3r>
well then, call it sun45i-foo and sunxi-foo
<mnemoc>
sunxi-emac, sunxi-gmac
<mnemoc>
family doesn't mean all socs are 100% compatible
<oliv3r>
bad example!
<mnemoc>
and diffs can perfectly be handled inside the *same* driver
<oliv3r>
i know, it was a bad example
<mnemoc>
i don't mean ethernet in particular
<oliv3r>
but what i tried to illustrade was, if some IP was used through 3 generations, but then swapped to something 100% different for the next few generations, that can still be handled in naming :)
<mnemoc>
just sunxi-foo/sunNi.c instead of sunxi-foo.c
<mnemoc>
and good glue
<oliv3r>
see, even prettier :p
<mnemoc>
but as a not-contributor I don't have the moral right to comment about those sun4i changes on mainline
<mnemoc>
neither rant here, so /me shuts up
<oliv3r>
mnemoc: yer perfectly right to rant too :p
<oliv3r>
Turl is who brought it up :) we can just ignore him on that :D
n01 has quit [Read error: Operation timed out]
<oliv3r>
mnemoc: when will you be 'back up and running'
<mnemoc>
I'll move this wed. (last working day of the month) ... but won't be really functional until the ~19th
<oliv3r>
3 weeks
<mnemoc>
I mean, ready enough to be able to dedicate to this
<mnemoc>
the other apartment doesn't even have electricity yet
<mnemoc>
and the weekend of the 13th I'll be traveling
<oliv3r>
well so no proper mnemoc until the 20th :)
<mnemoc>
right
<oliv3r>
:
<mnemoc>
techn_: still around?
<mnemoc>
or anyone with A13 or A10S? :)
<Turl>
*sigh* arch now opens .c with LibreOffice >.<
<oliv3r>
gentoo!
<mnemoc>
highlighted? :)
<Turl>
mnemoc: not even, reminds me of windows notepad.exe
<mnemoc>
ouch
<oliv3r>
that must be ages ago
<mnemoc>
notepad.exe learned to highlight C?
<oliv3r>
no windows :p
<Turl>
windows was like.. 2006-2008, I never remember correctly
<oliv3r>
2002 or 2003
<oliv3r>
when i completly kicked the habbit
<mnemoc>
win2k was the last I touched
<mnemoc>
and 98se the last I used
<mnemoc>
:p
<oliv3r>
lol
<oliv3r>
98se used
<oliv3r>
2k used; xp just barely
<Turl>
I used xp, touched vista and 7 on real machines
<oliv3r>
used slackware from 1997 though
<oliv3r>
a LOT
<Turl>
8 on a vm but the experience was so bad I nuked it :p
<Turl>
I still get to use xp once in a while at uni because the sysadmin forgot to install R on Ubuntu ~.~
<oliv3r>
i 'touched' Vista at work a few times
<oliv3r>
but not really used it
<oliv3r>
and 7 haven't touched
<oliv3r>
i have 'seen' 8
<oliv3r>
metro is 'HORRible'
<oliv3r>
but i like the idea on a phone/tablet
<oliv3r>
but you never heard me say that
<Turl>
lol
<oliv3r>
i don't say their exceution was worth anything though :)
calris has quit [Quit: Page closed]
<bsdfox_>
with I2C_DEBUG_CORE enabled writes are reliable. I tried adding a 5ms delay where the debug call is in the write function but it doesn't seem to help at all. Without debug I am able to write one single byte reliably but then the transfer fails with "incomplete xfer (0x20)"
<bsdfox_>
anyone got ideas where I should be looking?
<bsdfox_>
my guess is it's an ack/nack issue but I don't see anything interesting in the code