iamfrankenstein has quit [Ping timeout: 276 seconds]
geecko has joined #linux-sunxi
<geecko>
hi
geecko has quit [Client Quit]
geecko has joined #linux-sunxi
Soru has quit [Ping timeout: 264 seconds]
BluesBoy has joined #linux-sunxi
Ehsand has joined #linux-sunxi
soul has joined #linux-sunxi
n01 has joined #linux-sunxi
atiti has quit [Ping timeout: 268 seconds]
n01 has quit [Ping timeout: 268 seconds]
rellla has joined #linux-sunxi
<oliv3r>
goood mornin' everybody
<Super-noob>
good morning
eagles0513875_ has joined #linux-sunxi
<eagles0513875_>
hey guys im getting <6>Calibrating delay loop... during boot up on my cubieboard2 A20 any ideas as to whats wrong here
<oliv3r>
opwer
<oliv3r>
ot enough of it ;)
<rm>
so
<rm>
what's the problem
<rm>
it is a normal message
<rm>
or did you mean to say the boot up hangs/stops at it?
akaizen_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
wingrime has joined #linux-sunxi
<Super-noob>
rm: do you know how to directly write to the gpio pins(melebox) from ur debian image or where on the wiki i would find that ?
<rm>
no
eagles0513875_ has quit [Ping timeout: 250 seconds]
soul has quit [Ping timeout: 276 seconds]
deasy has joined #linux-sunxi
Quarx has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
Soru has joined #linux-sunxi
<mnemoc>
Soru: there is a gpio driver that takes the [gpio_para] section of your script.bin and expose those pins in /sys
popolon has joined #linux-sunxi
<popolon>
hi
rz2k has joined #linux-sunxi
focus has quit [Remote host closed the connection]
hansg has joined #linux-sunxi
vicenteH has quit [Ping timeout: 245 seconds]
FR^2 has joined #linux-sunxi
atiti has joined #linux-sunxi
popolon has quit [Read error: Connection reset by peer]
popolon has joined #linux-sunxi
popolon has quit [Read error: Connection reset by peer]
boycottg00gle has joined #linux-sunxi
popolon has joined #linux-sunxi
popolon has quit [Read error: Connection reset by peer]
iamfrankenstein has quit [Ping timeout: 256 seconds]
popolon has joined #linux-sunxi
popolon has quit [Read error: Connection reset by peer]
rz2k has quit []
benoitm974 has joined #linux-sunxi
<benoitm974>
good morning everyone. has anyone worked with sun7i dma ? I'm trying to use dam_compat from hans but can't find equiv to dma_setflags, should I code those ?
notmart has joined #linux-sunxi
popolon has joined #linux-sunxi
benoitm974 has quit [Quit: benoitm974]
atiti has quit [Ping timeout: 268 seconds]
eagles0513875_ has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
benoitm974 has joined #linux-sunxi
<eagles0513875_>
hey guys
<eagles0513875_>
i have something which is booting now, but my issue now has to do with it hanging on <6>Calibrating delay loop...
<eagles0513875_>
what am i missing at this point?
<mnemoc>
eagles0513875_: you were told before to try feeding more power to your board
<eagles0513875_>
mnemoc: i have the board plugged into a usb on the back of my imac
<eagles0513875_>
its getting power over usb
<mnemoc>
to usb-otg or DC-in ?
<mnemoc>
usb-otg is limited to 0.5A, but anyhow, both are limited by how much your computer can feed from that port
<mnemoc>
which might be <0.5A
<n01>
yep usb is always <0.5A
<n01>
'moning btw
<jinzo>
afaik usb can be >0.5A too
<jinzo>
specs say 0.5A minimum, but I have a charger here that's 1A
<n01>
afaik is limited in curret to prevent damages
<n01>
yep, but for chargers is different
<eagles0513875_>
mnemoc: usb to DC in
<eagles0513875_>
on the case it says 5V-2A
<mnemoc>
DC-in can take up to 2A, yes
<eagles0513875_>
morning n01
<mnemoc>
if your source provides it
<eagles0513875_>
a usb on another machine wont provide enough ?
<mnemoc>
so please try using a real AC/DC 5V from your other apple toys
<eagles0513875_>
sadly i dont have a 5c charger :(
hipboi has quit [Quit: Leaving]
<n01>
use the 220V then
<n01>
j/k
<eagles0513875_>
im a bit suprised that the usb isnt providing enough power
<n01>
2A is _a lot_ of current, just saying
<mnemoc>
the CB for example only needs >1A if you want to feed a sata drive
<eagles0513875_>
ok which at this point im not
<eagles0513875_>
what im struggling to figure out is why im getting that error im not quite understanding what it means
<mnemoc>
but 1A might be more than what you are feeding from your quack mac
<eagles0513875_>
mnemoc: then what is the issue the board is getting enough power to work and it works just fine with android
<eagles0513875_>
i think im missing something when i ran make in terms of a tweak or something
<n01>
mnemoc: don't be so harsh on the apple products ;)
<mnemoc>
quack
<n01>
lol
<mnemoc>
the usb chargers of apply devices usually give >2.1A
<mnemoc>
that's why I recommended it
<Turl>
howdy
<mnemoc>
wb Turl
<Turl>
hi mnemoc
<Turl>
mnemoc: how's the server move going? :)
<mnemoc>
builder is moved
<eagles0513875_>
mnemoc: so what you are telling me its a power issue?
<mnemoc>
only sunxi left
<mnemoc>
eagles0513875_: I don't know, but someone suggested that before
<eagles0513875_>
i find it hard to believe mnemoc
<eagles0513875_>
android with the usb in my imac a a source boots fine
<Turl>
eagles0513875_: can you paste the full log?
<eagles0513875_>
Turl: not really a log this is through the serial port
<Turl>
eagles0513875_: so? :P just copy and paste on pastebin or such
<Turl>
eagles0513875_: are you using a defconfig or something you made on your own?
<eagles0513875_>
Turl: defconfig modified using makemenuconfig
<n01>
multi_v7?
<Turl>
eagles0513875_: how long have you waited btw? I'm not sure if it was A20 or A31 but one of them suffered stalls because it had the caches off
<eagles0513875_>
Turl: this has been since yesterday evening
<Turl>
n01: this is 3.0 *scratches head*
<mripard>
Turl: not here at the delay loop
<mnemoc>
eagles0513875_: don't forget your android runs a different kernel. some things might be disabled there
<Turl>
eagles0513875_: how come you're using 3.0 on a sun7i?
<eagles0513875_>
3.0 of what
<Turl>
eagles0513875_: kernel 3.0
<mripard>
it's at decompression, and just after free_area_init_node
<eagles0513875_>
ahh well buildroot has support for the cubiboard a10 if need be i can update to the latest 3.10 kernel from git
<Turl>
eagles0513875_: A20 is only supported on (stage/)sunxi-3.4 and cubieboard2's 3.3 tree
<eagles0513875_>
Turl: 3.3 on
<Turl>
eagles0513875_: well, your log is booting a 3.0 kernel, I'm surprised it got that far tbh :P
<eagles0513875_>
Turl: what i was asking above 3.3 kernel and above should work correct
<mripard>
Turl: I'm not, the uarts are the same, at the same base address, the instruction set is the same, and the delay loop is the first time the kernel actually use the interrupts :)
<mripard>
(well, interrupts and timers that is)
<eagles0513875_>
ok let me try and use a newer kernel version
<Turl>
eagles0513875_: no, you need the special cubieboard 3.3 tree, or 3.4 from linux-sunxi, mainline won't work
<eagles0513875_>
Turl: hno told me to use the sunxi current branch which i am on
<Turl>
mripard: I thought A20 had a diff mach id though
<Turl>
eagles0513875_: that's uboot right? we're talking linux :)
<mripard>
Turl: hmm, right, but it seems to be detected as sun4i somehow
<eagles0513875_>
Turl: the repo title doesnt mention anything but an f20 there
<Turl>
eagles0513875_: meh, that's just because it's forked from linux-sunxi :P
<eagles0513875_>
oh ok
<eagles0513875_>
:)
<eagles0513875_>
Turl: couldnt i just clone the main stream kernel or will i have issues running it on arm
<Turl>
eagles0513875_: well, unless you plan on using just gpio I'd stick with this 3.3 tree or linux-sunxi's 3.4
<eagles0513875_>
Turl: i am pulling the latest commit from the git hub
<iamfrankenstein>
Hello
<iamfrankenstein>
Does anybody have any experience with the Debian Mali 400 drivers for the A13?
<iamfrankenstein>
I am getting a lot of tearing and i don't know why
<iamfrankenstein>
Any information is helpful a this point
<Turl>
ssvb: ^
<Turl>
iamfrankenstein: you need vsync to prevent tearing
* eagles0513875_
opts to go to lunch with my gf then come back maybe the kernel will be cloned by then lol
<ssvb>
iamfrankenstein: what application are you using that demonstrates this tearing?
<iamfrankenstein>
Qt5.10 with qt quick
atiti has joined #linux-sunxi
<ssvb>
with x11 or framebuffer mali drivers?
<iamfrankenstein>
framebuffer rp3p0-04
<ssvb>
framebuffer drivers don't do vsync, you need to add it manually
<iamfrankenstein>
oke! sounds interesting!
<ssvb>
you can try to add "ioctl(fb, FBIO_WAITFORVSYNC, 0)" immediately after "eglSwapBuffers" to Qt sources
<ssvb>
or alternatively you can try x11 drivers
<iamfrankenstein>
Ah thanks! i will try that
<ssvb>
in the case of x11 drivers, it is important to make sure that the framebuffer size is sufficiently large (fb0_framebuffer_num >= 3 in your fex file)
<ssvb>
in any case, the vsync and tearing problem is surely solvable
<iamfrankenstein>
good, because its for my gradiation asigment and its the last problemen in my system (and there were al lot of them). And i am not allowed to use X11 :)
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
<geecko>
Turl, got mali drivers compiling :)
<geecko>
now i have to setup configuration for the exynos 4210
benoitm974 has quit [Quit: benoitm974]
eagles0513875_ has quit [Ping timeout: 250 seconds]
boycottg00gle has joined #linux-sunxi
vinifr has joined #linux-sunxi
<vinifr>
mripard, sorry, you're right :)
<vinifr>
it seems that my brain is damaged :)
<oliv3r>
vinifr: context? :)
<vinifr>
3300mV*1000=3300000uV=3,3V
<mnemoc>
vinifr: forget about the units, the convertion there absuses the same variable for different things
<mnemoc>
3300mV*1000 is indeed 3.3V
<oliv3r>
didn't we talk abou tthe unit in register thing?
<mnemoc>
but the point is to get the uV equal to 3300mV
<mnemoc>
and so it gets multiplied by 1000.
<mnemoc>
because 3300mV is 3300000uV
<mnemoc>
but you only want the integer, not the unit
<mnemoc>
because working with uV lets you live float-less
<mnemoc>
and the kernel hates floats
<oliv3r>
i hate floats
<mnemoc>
:)
<oliv3r>
but i like exact sience
<oliv3r>
mripard: ping
<mnemoc>
if they use val_mV and val_uV instead of reusing val we wouldn't be having this discussion at all
<mripard>
mnemoc: it was not reusing val.
<mripard>
val had to be in uV
<mripard>
and I was using vref_mv to calculate it
<mripard>
vinifr: it's cool if you understand it then :)
<mripard>
oliv3r: pong
<oliv3r>
mripard: what branch has your most recent changes inc. a20?
<mnemoc>
:)
<oliv3r>
mripard: dt-for-sunxi-v3.12?
<mripard>
oliv3r: sunxi-next-a20-clocks
\\Mr_C\\ has joined #linux-sunxi
<mripard>
sunxi/*-for-* branches are the branch I'll send for the pull requests
<vinifr>
does anyone know if sunxi'LRADC has source clock?
<oliv3r>
yeah i figured those are most up to ate :)
<oliv3r>
vinifr: should be in datasheet
<mripard>
oliv3r: it depends really on what you want
<oliv3r>
mnemoc: what's the status of the new server?
<oliv3r>
mripard: a20 dt + a20 bootsupport
<mripard>
if you want what will be for sure in the next kernel version, take either sunxi/*-for* or even better, sunxi-next
<mnemoc>
oliv3r: the builder was moved. will try to move sunxi tonight
<vinifr>
yes, but i found nothing
<mripard>
all the other branches are rebased/modified/uncertain to be in the next version
<mnemoc>
oliv3r: give me your public ssh key if you want access. as long as you don't build android on it
<mnemoc>
but it can speed up a bit your kernel builders
<mripard>
oliv3r: then take the a20-clocks one
<oliv3r>
mnemoc: lol, i won't build android on it ;) can't you use the one you allready have?
<oliv3r>
mripard: i just need it to test SID on a20, so a20-clocks is good enough
<mnemoc>
oliv3r: accessing things from here is complicated, need to copy&paste on the phone :<
<oliv3r>
mnemoc: ohh
<oliv3r>
no rush
<mnemoc>
oliv3r: remind me tonight after 20h00
<oliv3r>
if i'm around, sure
<mnemoc>
it's up to you
<mnemoc>
I have 6*2 cores and 24GB of ram idling there
<oliv3r>
*drool
<mnemoc>
and i don't like to see idling hw
<oliv3r>
really? no android? :p
<mnemoc>
oliv3r: android is too big.... it can end up affecting the $official$ purpose of the machine
<oliv3r>
yeah no i know
<RaYmAn>
mnemoc: on a machine like that, android doesn't take more 10 minutes ;)
<mnemoc>
*g*
<mnemoc>
RaYmAn: and how much storage?
<oliv3r>
40gigs?
<RaYmAn>
hm
<RaYmAn>
yeah
<RaYmAn>
sounds about right
<RaYmAn>
if you don't keep too many builds around
<mnemoc>
then... maybe.... if it's only one android at the time...
<oliv3r>
sunxi-android
<oliv3r>
i wouldn't worry about it now
<oliv3r>
since we don't even have sunxi-android
<oliv3r>
but if we had it, then doing a weekly scheduled build wouldn't be horrible
<oliv3r>
well to have available for download anyway
<mnemoc>
i would like the bsp to be able to build multiple android images but without rebuilding the world for each board
<oliv3r>
weekly make all of the bsp would be awesome
<mripard>
the android build system in itself can do that in theory
<oliv3r>
dunno what our android status is
<RaYmAn>
mnemoc: that's a pretty damn beefy machine btw - is it personal or? And where and how much? :P
rah_ is now known as rah
<mnemoc>
RaYmAn: it's of a tiny webshop of a chilean friend, hosted on hetzer. 69E including 3 extra IPs "second hand" 4x1.5TB in raid10
<RaYmAn>
not bad
<oliv3r>
so instead of working through my mail, i'm building/testing code; i'm back to 843 unread
<oliv3r>
mmmm chilly
<oliv3r>
you made me hungry now
<mnemoc>
RaYmAn: and 20TB of traffic included
<mnemoc>
oliv3r: funny thing is that chile looks like a chili
<oliv3r>
mnemoc: lol how so?
<oliv3r>
mnemoc: lots of beans and corpses in tomato sauce?
<mnemoc>
look it at a map :p
<oliv3r>
ohh a chilly bean
<oliv3r>
chili pepper?
<oliv3r>
i meant the dish :)
<mnemoc>
yup
<oliv3r>
but yeah it does
<oliv3r>
NL looks like ... nothing :p
<RaYmAn>
mnemoc: yeah, that's pretty good :) I have one of the smaller ones (quad core, 16gb ram, 2x3tb sata, 20tb traffic and 4 extra ips - guess I ordered when they allowed that?)
<oliv3r>
mripard: i suppose there's no pretty way to write clocks = <&apb1_gates 16>; not using a magic number? e.g. no defines right?
<mripard>
mnemoc: don't know how it's called in spanish, but in french, chile is actually called Chili :)
<mnemoc>
RaYmAn: their second hand store is awesome
<oliv3r>
mripard: same for NL
<mnemoc>
mripard: in spanish both are chile :p
<mripard>
oliv3r: yes
<RaYmAn>
mnemoc: yeah - usually I haven't seen a lot of high-ram ones there though. Also, the issue of loosing an ip if I switch :(
<mnemoc>
mripard: weird the chili name for chili pepper comes from nahuatl (.mx) and those we named the country chile where inca (.pe) and they had no idea about the actual shape of the full thing
<mnemoc>
RaYmAn: 1E per IP, not that bad
<mnemoc>
s/where/were/
<RaYmAn>
mnemoc: yeah, but I have main ip plus 4 now..They only allow plus 3 on new :(
deasy has quit [Quit: Quitte]
<mnemoc>
but the best part is that the friend is in .cl, so he doesn't pay .de VAT for the machine
<oliv3r>
mnemoc: do you grow a lot of peppers in chile?
<RaYmAn>
oh, that's cool
<mnemoc>
oliv3r: not at all
<mnemoc>
oliv3r: we do apples, grapes, salmon and cooper mostly
<mnemoc>
and wine
<oliv3r>
oh i've had your apples and grapes
<oliv3r>
wine i know of, but i don't drink wine so ..
<oliv3r>
as copper, i'm sure i speak for all, i'm sure we have that somewhere :D
<mnemoc>
it's so funny that most wineyards are owned by french, and they label the wine as french....
<mnemoc>
using the "made in $smalltownwithoddname" on it, instead of the country
<mripard>
mnemoc: it's the same thing in california, most of the wineyards are owned by french
<mripard>
(well, if not most, more and more)
<mnemoc>
evil frenchs....
<oliv3r>
lol
<n01>
agree lol
<oliv3r>
i was in paris a few months ago, and had a waiter, that poured himself a glass for every bottle he served
<oliv3r>
sometimes two
<mripard>
there's one thing we do well, don't take it away from us :)
<oliv3r>
he was quite drunk at the ende
<n01>
oliv3r: I was in NL past week
<oliv3r>
n01: really? weed-run? :p
<oliv3r>
and then he said 'tip is not included'
<oliv3r>
but the check said '15% service compris' as its' always included
<n01>
yeah lol ... amsterdam, laiden, rotterdam
<mripard>
oliv3r: yeah, tips are weird in france
<n01>
*leiden
<oliv3r>
he even 'misteknly' added 9 euro's to the bill
<mripard>
I can't remember the last time I gave a tip in france
<oliv3r>
charged 54 instead of 45
<mripard>
and it's normal for french
<mripard>
but waiters get pissed when a stranger doesn't give a tip
<oliv3r>
but he did that before even talking about the tip
<oliv3r>
but yeah, same here, we don't generalyl tip (much) in NL either
<oliv3r>
max 5%
<mripard>
yeah, well, mistakes happen, it might just be a coincidence :)
<oliv3r>
yeah he was drunk
<oliv3r>
:p
<oliv3r>
but we left him like 1 or 2 euro's anyway
<oliv3r>
he wasn't very nice either anyway
<oliv3r>
which was a shame, we had a good day
<oliv3r>
the louvre was way to big though ;)
<mripard>
yes, you need at least a day to see a significant part of it
<oliv3r>
but we walked around the city, took a train, a subway
<oliv3r>
had nice weather
<oliv3r>
so it was a good day
<oliv3r>
but exhausting
<oliv3r>
getting up at 3 am, to take a bus and be back 26 hrs later, exhaustive
Ehsand has quit [Quit: Leaving.]
<oliv3r>
mripard: so with a20-clocks branch, we can use 1 kernel for both a10 and a20, right?
<mripard>
yep
<mripard>
and even your rpi or your marvell nas if you feel like it
<oliv3r>
;)
<oliv3r>
much easier to test hten
<oliv3r>
just need to load different dtb and have different u-boot
<oliv3r>
damnit I thought I had fixed the wemac, but it's still malfunctioning it seems, so either it worked and broke again, or something else is wrong
<oliv3r>
my guess is, that some power regulator is messing things up :S
<mripard>
sunxi-pinctrl: probe of 1c20800.pinctrl failed with error -22
<oliv3r>
let me build clocks-a20 without my patch
<oliv3r>
merging of my tree and your tree was giving headaches
deasy has joined #linux-sunxi
<oliv3r>
mripard: same thign
<oliv3r>
wrong dts?
<oliv3r>
was that changed recently?
<mripard>
on the cubie1?
<oliv3r>
yeah
<mripard>
not that I can recall
<oliv3r>
let me clean my tree for good measure
<mripard>
tbh, I don't have a cubie1, and didn't test my patches on !A20 hardware
<mripard>
so it might very be broken for some time
<mripard>
and that I didn't notice
<oliv3r>
i'm building a clean tree now
<oliv3r>
new dtb with clean kernel works
<oliv3r>
let me swap to my own kernel now
<oliv3r>
seems to work now i i got the right kernel, so seems like dtb change
<oliv3r>
or i forget to load the kernel
<oliv3r>
oh no, i use the other dts, no sid in it
<oliv3r>
duh
<oliv3r>
mripard: false alarm, all works with new dtb
<oliv3r>
rellla: ping
<rellla>
oliv3r?
<oliv3r>
rellla: oh hi :)
<oliv3r>
rellla: can we boot/use xbmc on a20 reliably allready with mpeg2/h264 decoding?
<rellla>
i haven't tested it. first i must make my a20 boot...
<vinifr>
mripard, I got to boot kernel-mainline in A13 and A10
<oliv3r>
rellla: what's the problem?
<rellla>
oliv3r: time :p
<oliv3r>
rellla: do you have mele m5 or cubie2?
<rellla>
cubie2
<oliv3r>
rellla: time is easy :p
<vinifr>
cubie1 and a13-olinuxino
<oliv3r>
rellla: ah good :) same hardware
<oliv3r>
rellla: making a20 boot is easy :p
<oliv3r>
rellla: u-boot on github should work
<rellla>
oliv3r: default branch?
<mnemoc>
sunxi
<mnemoc>
hno already merged the stuff
<oliv3r>
rellla: yep :)
<rellla>
does stage/sunxi-3.4 also work or should i wait for merging hansg's
<oliv3r>
rellla: hansg's tree probably is the most advanced now
<mripard>
oliv3r: cool, nothing to worry about then :)
<oliv3r>
mripard: not yet ;)
<mripard>
and so, your sid driver work +
<mripard>
?
<mnemoc>
problem with previous incarnations of hansg's tree is that it's a20-only
<mnemoc>
and tends to break others
vinifr has quit [Quit: Saindo]
<hansg>
mnemoc, that is not true
<mnemoc>
hansg: do you have a for-amery for me? :)
<hansg>
As I've said before I build and run it on all 3 of sun4i / sun5i / sun7i
<oliv3r>
i really should clean up my sunxi-bsp git and push it somewhere
<oliv3r>
i think ssvb found some issues
<mnemoc>
hansg: great
<oliv3r>
but that's all i heard of it
<hansg>
It sometimes breaks for others because the have a different config and or toolchain, not because I support a20 only. I'll admit it still breaks sometimes, but is impossible for me to test all permutations
<mnemoc>
hansg: i would like to merge your stuff, then merge to non-stage, tag, and jump forward to the last 3.4.y
<rellla>
mnemoc, hansg, oliv3r: that's one reason, why i did wait. all the patching is a bit confusing for me for now ;)
<hansg>
mnemoc, sounds good to me.
<mnemoc>
in my case I test the defconfigs
<oliv3r>
rellla: ok wait till after the merge :p
<mnemoc>
which are also only one possible variant of CONFIG_s
<rellla>
oliv3r: and then test, if/how cedar_dev works.
eagles0513875_ has joined #linux-sunxi
<eagles0513875_>
hey guys :)
<rellla>
rootfs/binaries should be the same, right
<rellla>
?
<bfree>
has anyone tried grub's arm-uboot (on sunxi)?
<oliv3r>
rellla: if :S
<oliv3r>
rellla: armv7 yes, but libcedar.so could be different, that we don't know yet
<oliv3r>
or I don't
<rellla>
mnemoc: when merged, we should go on with trying newest mali
<rellla>
oliv3r: ypu mean libvecore.so?
<hansg>
mnemoc, there is a new sunxi-3.4-for-amery at my github now. Highlights: a20 usbc0 and nand support, fix ohci controller not working on sun5i, unified sunxi-ir driver, tons of usb cleanups
<ynezz>
hansg: hm, it can boot from nand?
<hansg>
mnemoc, I must admit I did not test with defconfig_foo lately, but I don't think were many changes which may have broken that. If there are any issues ping me , or if I'm not on irc drop me a mail
<oliv3r>
rellla: CedarX :p
<hansg>
ynezz, with a proper config, I would not see why not. Note this is the kernel only. I don't know about u-boot for nand.
<ynezz>
nice!
<oliv3r>
u-boot still doesn't do nand, unless you take the old dump
<oliv3r>
rellla: i noticed you merged rudi's cedarX patches, did you manage to reproduce the bug?
<rellla>
oliv3r: no :p
<hansg>
mnemoc, btw I realize I've latley been sort of acting as a gate-keeper (or more of a vacuum cleaner) for linux-sunxi patches (at least for 3.4), since you seemed quite busy, and well someone had to do it. But now that I'm more or less done with bringing a20 support to sunxi-3.4 (felt more useful then backporting all my hdmi / edid stuff too 3.3) I plan to stop doing that and focus more on working upstream, which should make mrip
<hansg>
ard happy :)
<oliv3r>
rellla: so just merged it anyway? :)
<hansg>
^^ make mripard happy that is, my irc client picked a bad place to cur that line
\\Mr_C\\ has quit []
<oliv3r>
hansg: yay mainline!
<hansg>
mnemoc, so we will need someone else to keep an eye on linux-sunxi patches and keep a tree where they are merged. So assuming you're still busy otherwise we should probably look for a volunteer for that
<mnemoc>
hansg: the point of bringing a20/a31 support into 3.4 is to have a safer test field for unification
<hansg>
mnemoc, right having a single unified tree is a big reason for my 3.4 a20 work too
<mnemoc>
hansg: I'm mostly settled now. and already moved my build server
<rellla>
oliv3r: rudi seemed reasonable, and no negative effect so far...
<mnemoc>
hansg: the most annoying problem is the >3000 unread mails on the ML :(
<oliv3r>
rellla: good good, hope he noticed ;)
<oliv3r>
mnemoc: 850 :(
<mnemoc>
hansg: but if you can give me an starting point I can start taking full care from there
<mnemoc>
hansg: let say.... today? :)
<hansg>
mnemoc, for the last few months I've been merging any patches which looked sane (or asked people to fix them up and resend). There has been a window before that where no-one was merging patches, but that is a long time ago, most of those have been resend
<mnemoc>
everything older is in your for-amery. anything newer I review/apply/test after merging yours
<rellla>
oliv3r: but i still don't understand why our libvecore.so should not work with a20? assuming that there was no change in accessing cedar_dev
<hansg>
So yes I think starting today would be good. I still have 2 unmerged patches, but other then that just marking everything on the list uptill now is good.
<oliv3r>
rellla: updated hardware is my fear
<hansg>
s/marking/marking read/
<oliv3r>
rellla: just one change in register could break it all
<mripard>
hansg: yay :)
<mnemoc>
hansg: great :)
<rellla>
oliv3r: so it's time to find it out.
<oliv3r>
rellla: :D
<oliv3r>
hansg: what are you working on first? :)
<rellla>
oliv3r: i'll do it, after i finished my new C and arduino books ;) c for beginners. electronics for beginners :)
<hansg>
mnemoc, so the 2 unmerged patches are: "[PATCH v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)" which has progressed greatly, but I'm not sure is actually in working / tested condition yet.
<Turl>
rellla: :P need to read K&R to learn C
<hansg>
And: "[PATCH v1 1/1] [stage/sunxi-3.4] use ahci platform driver for sunxi sata device", which keeps getting mangled by the senders mail-client (I've not yet tested the last version)
<mnemoc>
H&S is much better than K&R
<oliv3r>
we have no hardware for the DVB-TS
<rellla>
woprr ^
<oliv3r>
so hard to say
<mripard>
Turl: and then you'll see the light :)
<mnemoc>
even if i can be called heretic
<oliv3r>
but having it there to start with is good
<Turl>
mripard: it's the One True Way of C :)
<oliv3r>
i ove my K&R, got both the digital and paper versions
<hansg>
oliv3r, the first thing I want to upstream is mmc support, the new (from the sun7i-3.3 sources) drivers/mmc/sunxi-mci.c driver looks like a promising start for that
<hansg>
oliv3r, mripard, AFAIK someone is already working on mmc support for upstream, right ? Any news on that ?
<mripard>
hansg: yeah, it's what I've used to start with cleaning up
<mnemoc>
hansg: can you paste me those two subjects and the branch on /q ? so I can take a look after work?
<woprr>
DMA not working only PIO polling and no dvb api (device files) nor i2c/tuners yet
<mripard>
I didn't make much progress, I can push what I have so far and let you pick it up from there
<Turl>
mnemoc: 560 pages?! did Stroustrup write it? :P
<mnemoc>
hansg: or they'll get lost on the buffer :<
\\Mr_C\\ has joined #linux-sunxi
<hansg>
mripard, that would be great, it is always good to have a head start :)
<hansg>
mnemoc, np, I'll /q them to you
<mnemoc>
hansg: thanks!
<mnemoc>
Turl: the best C99 book
<oliv3r>
mnemoc: your books never arrived!
<rellla>
Turl, mnemoc: thanks. i'll check it if pointers haven't made me mad after my noob-book
<oliv3r>
mripard: not sure why, might be other issue,
<mripard>
I probably broke some stuff in the process, it's not even compiling :)
<Turl>
mnemoc: K&R is shorter and gets the job done :)
<mripard>
hansg: you've been warned :)
<mnemoc>
Turl: but doesn't teach you C99
<oliv3r>
i think it's u-boot, so let me cross that off the list
* rellla
maybe should do some perl instead
<mripard>
oliv3r: do you have your branch somewhere?
<oliv3r>
in a possible broken state, sure
<oliv3r>
let me see if I can boot this
<Turl>
mnemoc: and by shorter I mean half the pages
<Turl>
mnemoc: the last edition is pretty up to date
<oliv3r>
there's a new edition? :)
<woprr>
maybe DMA, see some contigous buffer code
<Turl>
oliv3r: the one with the ANSI C red stamp
<hansg>
mripard, thanks. So did at one point in time have this working (as in building + booting + being able to read from an sdcard) ?
<Turl>
rellla: perl :S
<oliv3r>
mripard: i pushed it to my github, security-id, but have to go home now so can't test a20 further, not booting :(
<oliv3r>
u-boot something
<mnemoc>
oliv3r: I brought only 60kg in programming books with me, the other 120kg are still waiting in a warehouse in spain :p
<mnemoc>
Turl: ansi = c89, ancient
<mnemoc>
Turl: up to date means c11
<mripard>
hansg: nope. We don't have any of the API used in the sun7i-3.3 kernel, so that never compiled
<mripard>
hence why I mostly focused on removing the irrelevant API calls (clocks, pinmuxing, etc.) to get it compiled
<woprr>
hardware? well, easy get an old dvb-c pci card and demount the receiver tin can box, connect it to SMT of olimex/cubie, but you need some userspace tool/sw giving the /dev/tsc_dev ioctl() cmds
<oliv3r>
lol 'easy' :)
<woprr>
datasheet for philips CU1216 MK I...III is online
<mnemoc>
Turl: btw, you can find c11 by searching for n1570.pdf
<Turl>
mnemoc: there's like... 2 real-life changes from c89 to c11 :P
<boycottg00gle>
anybody got a olimex a20 with working hdmi?
<Turl>
mnemoc: namely, dynamic arrays
<woprr>
only 10-30 pins and a 1.8v regulator
<mnemoc>
Turl: no way. there are a ton of real life changes from c89 to c99
<oliv3r>
woprr: sure, easy ;)
<oliv3r>
woprr: have you made it work yet? :)
<woprr>
next weeks
<Turl>
mnemoc: name 5 that matter and I'll let you win the argument :)
* mnemoc
wants to see the new misra .... they finally switched to c99
<hansg>
boycottg00gle, yes, you need to use the latest fex file from sunxi-boards, the older one had the display configured for sending output to an lcd display
<mnemoc>
Turl: low prio thread on irc, can't think of any atm
<mnemoc>
Turl: because here I'm not thinking
<mnemoc>
brain is still at $work$
<hansg>
Talking about $work$, it was fun guys, but I really need to get some $work$ done now, see you all later
<boycottg00gle>
hansg: i think i already have the latest fex. may ask which uboot, kernel you use and do you use any special kernel args?
<Turl>
ssh mnemoc renice -n -20 -p $(pidof irc)
<eagles0513875_>
hey Turl and mnemoc :)
<Turl>
j/k :)
<mnemoc>
Turl: :)
<Turl>
hi eagles0513875_
<hansg>
boycottg00gle, if you use the latest fex (converted to script.bin) + my Fedora-19 images it should work
<eagles0513875_>
still waiting on the kernel to download lol
<eagles0513875_>
ubuntu does some wonky shit when mac osx locks
<boycottg00gle>
hansg: my sd card unfortunately is to small :(
<eagles0513875_>
the screen
<hansg>
boycottg00gle, sorry got to go now
<boycottg00gle>
hansg: np, thx anyway - will get a bigger one soon
<mnemoc>
eagles0513875_: and add extra remotes upon that
<mnemoc>
faster than a real git clone
<atsampson>
Turl: inline variable declarations, intNN_t types, variadic macros, struct initialisers and snprintf are all C99 things I use in real code all the time (and I've used dynamic arrays once or twice, but could live without them)
<jelly-home>
a guy in #arm-netbook yesterday said his chromebook 3 had a mali t604
<jelly-home>
whatever that might be
<mnemoc>
oliv3r: ping
<oliv3r>
mnemoc: pong
<mnemoc>
/q
Soru has quit [Read error: Connection reset by peer]
Soru has joined #linux-sunxi
<eebrah>
jelly-home, the GPU
hramrach has quit [Ping timeout: 240 seconds]
benoitm974 has joined #linux-sunxi
hramrach has joined #linux-sunxi
xtofury has quit [Ping timeout: 246 seconds]
shineworld has quit [Remote host closed the connection]
dwilkins has quit [Ping timeout: 264 seconds]
dwilkins has joined #linux-sunxi
benoitm974 has quit [Ping timeout: 264 seconds]
benoitm974 has joined #linux-sunxi
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
notmart has quit [Quit: notmart terminated!]
<andoma>
[A
<oliv3r>
[B
robb83 has joined #linux-sunxi
<robb83>
hi
benoitm974 has quit [Ping timeout: 264 seconds]
tinti_ has quit [Quit: Leaving]
benoitm974 has joined #linux-sunxi
<Turl>
oliv3r: so what happened with SID? :P
<oliv3r>
didn't you read earlier today?
<oliv3r>
works on a10, need to get my a20 booting, so will fix that tomorrow @work
jemk has quit [Ping timeout: 246 seconds]
<oliv3r>
then it should work on a10 AND a20
benoitm974 has quit [Ping timeout: 264 seconds]
<mripard>
mturquette: sunxi-clocks-ping :)
<mturquette>
mripard: i'm-on-it-pong
<mripard>
mturquette: great then :)
<oliv3r>
anybody have a clockgenerator i could use?
<Turl>
oliv3r: tick
<Turl>
oliv3r: tock
<Turl>
oliv3r: tick
<Turl>
oliv3r: tock
<Turl>
good enouth? :)
<Turl>
enough*
<oliv3r>
ok, could you plug yourself into my attiny84's clock in pin?
<oliv3r>
so i can fix the fuses?
<Turl>
you'll be better off using a gpio :p
<Turl>
mturquette: awesome :)
benoitm974 has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
geecko has quit [Ping timeout: 256 seconds]
wingrime has quit [Read error: Operation timed out]
xtofury has joined #linux-sunxi
<xtofury>
anybody know how I can tell if I am working with a defective cubieboard in relation to the touchscreen controller. It just does not want to work... :(
<xtofury>
I'm trying to use the resistive controller built in, have CONFIG_INPUT_TOUCHSCREEN=y in the cubieboard defcon, and checked out my script.bin using bin2fex, all is good with those two, am I missing something? Because it doesn't even register a tap or anything...
<xtofury>
and i know the panel is working because I tested it on my laptop using an egalax controller.
<Turl>
xtofury: and did you load the right kernel driver?
<Turl>
xtofury: should be sun4i-ts.ko
<xtofury>
now that is just weird, this sdk came with that line CONFIG_INPUT_TOUCHSCREEN=y in the file, but no kernel driver?
<xtofury>
lol
<Turl>
you should have CONFIG_TOUCHSCREEN_SUN4I_TS=y
<xtofury>
ummm this is for a cubieboard right?
<xtofury>
man everybody's got a different set of instructions...
<xtofury>
ok I'm gunna do a make -j3 again tonight, and am just wondering how I can toss this in there, I thought it was supposed to be sun4i-ts.ko
<xtofury>
ahhh found it here sun4i-ts.ko
<xtofury>
I swear my card is defective....
<xtofury>
sorry meant sun4i-ts.c
<xtofury>
I'm not finding anything in the makefile or kconfig for /kernel/allwinner/common/drivers and I'm thinking there should be something in there....
<Turl>
en?
<Turl>
eh?*
<Turl>
the driver is in drivers/input/touchscreen/
<xtofury>
yeah the .c file is in there.
<Turl>
and makefile there says obj-$(CONFIG_TOUCHSCREEN_SUN4I_TS) += sun4i-ts.o
bsdfox\ has quit [Ping timeout: 240 seconds]
<Turl>
and kconfig there has the symbol
<xtofury>
yes makefile is good.
<xtofury>
checking the kconfig
<xtofury>
you mean this part : config TOUCHSCREEN_SUN4I_TS
<xtofury>
looks good...... I am lost here it looks like this sdk was configured by default to work with a resistive touch panel....
<xtofury>
sigh ok I'm just gunna write tom, I swear this cubieboard is defective.
<Turl>
did you even test it yet? :P
<xtofury>
test what? The touch panel? yes on my windows laptop it works fine over an egalax usb interface.