Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
aesok has quit [Remote host closed the connection]
<rz2k> TheSeven: there are couple parameters that you can set via kernel command line. http://linux-sunxi.org/Kernel_arguments
rz2k has quit []
<hno> TheSeven, SPI for sun7i whould be the same as for sun4i I think.
<TheSeven> hm... "Error: unrecognized/unsupported machine ID (r1 = 0x00000f35)."
<TheSeven> and it claims to support 10bb/102a/1088
<TheSeven> any hints what might be the cause?
<hno> TheSeven, mismatch between u-boot and kernel..
<TheSeven> I upgraded from some allwinner 3.3 to linux-sunxi 3.4
<TheSeven> what do I need to fix in uboot?
<hno> either use linux-sunxi u-boot, or set machid to the proper registered id.
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<TheSeven> which one of those above is the right one? (or how do I find out?)
popolon has quit [Quit: Quitte]
<TheSeven> this is an A20-onlinuxino board
<TheSeven> ah, I think I found it
<TheSeven> so 4283/10bb would be the right one
<hno> sun7i MACH_SUN7I SUN7I 4283
<TheSeven> thanks :)
<TheSeven> hm, could it be that lzo compression/decompression for the kernel is broken somehow?
<TheSeven> gzip/xz seem to work, lzo hangs on boot, before the kernel produces any output
Gerwin_J has quit [Quit: Gerwin_J]
miseria has joined #linux-sunxi
<miseria> "mi silencio no es estar callado, ni mi soledad un lujo robado, mi palabra es sincera, pero siempre prisionera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
miseria has quit [Client Quit]
jinzo has quit [Quit: Leaving]
<TheSeven> what's the correct order in which to load ump/mali/disp/lcd/hdmi?
<TheSeven> actually I'd like to just compile them in, but apparently that doesn't work
<TheSeven> right now attempting to load disp fails with erros like this: "disp: Unknown symbol cfb_copyarea (err 0)"
<hno> TheSeven, I don't know. Prefer letting u-boot handle decompression.
<TheSeven> hm, another feature I'm not aware of...
<hno> you either use an uncompressed uImage with a (b)zimage in it, or a compressed uImage with an uncompressed image in it..
<hno> in the first u-boot knows how large the kernel is and can adjust initrd/fdt placements accordingly.
<hno> in the latter u-boot can only guess, and kernel might try to move things around if needed.
<Md> why there is no /proc/kcore? (I'm using rm's kernel)
<Turl> TheSeven: they're built in by default
<TheSeven> hm, but something didn't work with that setup... I'll check again
<TheSeven> I read some mailing list chatter that things get initialized in the wrong order when they're built in
<TheSeven> is it really normal that the kernel takes ~6 seconds to decompress itself with gzip and ~30 seconds with xz? that seems awfully slow for a 3MB=>7MB inflation...
<TheSeven> does it run with caches off or something like that?
<Turl> TheSeven: as far as I recall they were all defaulted to builtin some time ago because they needed a very magic loading order and it failed
<Turl> TheSeven: on uboot? or post uboot?
<TheSeven> measured from uboot handing over to first earlyprintk message
<Turl> odd
<Turl> it usually takes <1s on my experience
<Turl> I use lzo, but gzip et al were around the same
<Md> TheSeven: xz is slower than gzip, but 5x looks like a bit too much
<TheSeven> not only that, but 6 seconds for gzip seems terribly slow as well
<Turl> it is
<TheSeven> and LZO (supposed to be fastest) didn't finish before I gave up and rebooted it
<Turl> you are on a20 right?
<Turl> ct?
geecko has quit [Ping timeout: 272 seconds]
<TheSeven> so for mali I'd just set CONFIG_MALI=n, CONFIG_MALI400=y, CONFIG_UMP=y, CONFIG_FB=y, CONFIG_FB_SUNXI=y and CONFIG_FB_SUNXI_LCD=y?
<TheSeven> Turl: a20-olinuxino
<Turl> TheSeven: all to =y I'd say
<Turl> TheSeven: there's also another one SUNXI_HDMI or sth like that
<Turl> I believe you need all of them
<TheSeven> yes, I don't care about HDMI right now, but I enabled it anyway
<TheSeven> CONFIG_MALI is "ARM Mali GPU modules" (This enables the generation of mali.ko and ump.ko.)
<TheSeven> if I enable that as well, compilation fails
<TheSeven> that can only be set to m, not y
<TheSeven> and IIUC CONFIG_MALI=m conflicts with CONFIG_MALI400=y or something like that
<Turl> TheSeven: mali cannot be builtin, only module
<TheSeven> right, so what do I need to set to what now? :)
<TheSeven> disp builtin but mali as a module? what about UMP?
<Turl> ump is built together with mali
<Turl> mali.ko and ump.ko
<Turl> disp is all builtin
<TheSeven> interesting... it wasn't in the allwinner 3.3 image that I was using previously
<Turl> 3.3 is allwinner's
<Turl> so it has allwinner config names and such
<Turl> they do it as a module, yes
<Turl> loaded in this very magical order
FDCX has quit [Ping timeout: 264 seconds]
servili007 has quit [Read error: Connection reset by peer]
<TheSeven> Turl: so what could cause this to just show a black screen and have surfaceflinger restart over and over?
<Turl> TheSeven: mismatching mali libs?
<Turl> what does logcat say?
<TheSeven> indeed
<TheSeven> E/ ( 1380): ERROR in Mali driver:
<TheSeven> E/ ( 1380): * Mali device driver failed the API version check
<TheSeven> E/ ( 1380): * The solution is probably to rebuild the libraries and the Mali device driver.
<Turl> easy to fix then, use the right libs :)
<Turl> r3p0 if you use linux-sunxi
<TheSeven> do I just have to replace the binaries in /system/lib/egl/? or is there more to this?
<Turl> TheSeven: those 3, as well as libMali and libUMP on system/lib/
<TheSeven> hm, in that archive there's also a file named gralloc.sun4i.so
<TheSeven> I have a gralloc.sun7i.so and grallic.default.so in /system/lib
<TheSeven> replace the sun7i one with the sun4i one?
FDCX has joined #linux-sunxi
<Turl> no, don't replace it
<TheSeven> ok, I left that one alone and rebooted, now I have a very choppy boot animation
<TheSeven> as in 1-2 fps
<Turl> are you building your own android?
<TheSeven> so that's some progress at least :)
<Turl> or using aw sdk=
<TheSeven> aw sdk
<Turl> I bet you lack vsync
<TheSeven> it wasn't that sluggish with the AW kernel
<Turl> probably never added it to linux-sunxi from the newer sdks yet
<TheSeven> that worked just fine
pitillo has quit [Ping timeout: 245 seconds]
<Turl> yeah you can probably check logcat again
<Turl> and it'll complain vsync is timing out constantly or sth like that
<TheSeven> yep
<TheSeven> so... how do I fix that?
<Turl> you'll need to find out what did aw add to the new disp and add it to linux-sunxi
<Turl> probably some uevent or sysfs stuff to deal with vsync notifications to userspace
<TheSeven> so that's kind of a known bug in sunxi-3.4?
<Turl> probably more of a "nobody needed it so far"
<TheSeven> hm... I might look into that tomorrow
<TheSeven> it's past 3AM :/
<TheSeven> anyway, do you have some hints what I could poke at?
<TheSeven> diffing disp source code?
<Turl> yeah, diffing or looking around
<Turl> may want to talk with the graphics people here too
<Turl> I just took the lazy way out when I hit the issue some time ago and hacked around the problem
<TheSeven> anyway, thanks for your very helpful information :)
<TheSeven> that surely saved me some hours of digging around
<Turl> TheSeven: if you just need a hack until you can fix that, you can have a look at the hwcomposer changes in https://github.com/allwinner-dev-team/android_device_allwinner_common/commits/cm-10.1
<Turl> it's not the same hwcomposer, but you can probably pick the gist of it and get something good enough running until you can fix the underlying issue
<Turl> ("Update hwcomposer to 1.0" and "Fake vsync the "right way"")
<TheSeven> do you think that the underlying issue is within disp or lcd?
pitillo has joined #linux-sunxi
<Turl> probably disp, but I'm just blind guessing now
<TheSeven> that's probably a more educated guess than mine though :)
<Turl> :)
<Turl> aw code is full of surprises though
<TheSeven> Turl: that seems related, eh?
<TheSeven> /add by heyihang.Jan 28, 2013
<TheSeven> __s32 DRV_disp_vsync_event(__u32 sel)
<Turl> yep, sounds like that's it
<TheSeven> ends up doing a kobject_uevent_env(&g_fbi.dev->kobj, KOBJ_CHANGE, envp); with envp being set to a string "VSYNC0=<some_timstamp>"
<Turl> yep, and that's then received by hwcomposer and passed to android
zeRez_ has joined #linux-sunxi
<TheSeven> it's hooked into LCD_vbi_event_proc
<TheSeven> which already exists in the linux-sunxi code base
<TheSeven> let me try naively porting that...
<TheSeven> grepping for "//add by heyihang.Jan 28, 2013" should help :)
* TheSeven skips the fpga-debug-related mess
zeRez has quit [Ping timeout: 246 seconds]
zeRez_ has quit [Quit: zeRez_]
zeRez has joined #linux-sunxi
<TheSeven> aaaarggh
<TheSeven> include/linux/drv_display.h:DISP_CMD_VSYNC_EVENT_EN = 0x2b,
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<Nyuutwo> TheSeven: are you sending commands setting something for LCD?
pitillo has quit [Ping timeout: 265 seconds]
<TheSeven> what kind of commands do you mean?
<Nyuutwo> TheSeven: this could explain why I have got same values in registers for LCD but it doesn't work on sunxi but works in stock android
<TheSeven> you mean some kind of panel init commands?
<TheSeven> no idea, boot1 is taking care of that apparently
pitillo has joined #linux-sunxi
<Nyuutwo> LCD connected with LVDS (haven't got yet time to probe LVDS lines others seems that doesn't change anything)
<Nyuutwo> I disassembled and it looks like boot1 doesn't do anything (oh glorious nonstripped elf files)
<TheSeven> well, maybe it's boot.axf
<TheSeven> you know there's source for it?
<Nyuutwo> TheSeven: probably there isn't - cheap chineese tablet
<Nyuutwo> could'nt find info for LCD panel either
<Turl> TheSeven: have fun :) if you get it working please send a patch to the list :)
<TheSeven> no idea about your particular device - but there's this: https://github.com/hno/allwinner-boot/tree/lichee-a20-dev/boot1/driver/drv_de/de_bsp/lcd
<Turl> I'll get some sleep
<Turl> good night! :)
<Nyuutwo> TheSeven: thanks, will check wether it is similar
<Nyuutwo> TheSeven: looks similar but it has other functions for initializing other types of LCD
<TheSeven> shouldn't most of the panel specific things be abstracted in the fex file?
<TheSeven> Turl: fixed it :)
<TheSeven> that was 100% straightforward
<TheSeven> at least the boot anim is smooth now
<TheSeven> hm, looks like something still isn't quite right though
Vertex_ has joined #linux-sunxi
<Vertex_> does anyone has luck with setting up bluetooth on Cubietruck (a20)?
<Nyuutwo> Rocky get lcd_value failed - this line from boot1 is interesting
pitillo has quit [Ping timeout: 252 seconds]
pitillo has joined #linux-sunxi
NermaN has joined #linux-sunxi
<NermaN> Hi all, in what state now 3.10? Is it suitable for server use?
hipboi has quit [Ping timeout: 272 seconds]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
zeRez has quit [Quit: zeRez]
Md has quit [Quit: si hoc legere scis nimium eruditionis habes]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
prasannapete has joined #linux-sunxi
Quarx has joined #linux-sunxi
<ganbold> where can I download latest version of emac driver?
hipboi has quit [Quit: Leaving]
hipboi has joined #linux-sunxi
cubear has joined #linux-sunxi
Quarx has quit []
<JohnDoe_71Rus> oliv3r: Hi. linux kernel build successful. Around 2 hours.
Black_Horseman has quit [Ping timeout: 245 seconds]
<JohnDoe_71Rus> oliv3r: but build kernel for android get error http://pastebin.com/mypTFG0P
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-sunxi
Jerry_ has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
hipboi has quit [Ping timeout: 265 seconds]
Taduro has joined #linux-sunxi
rellla3 has joined #linux-sunxi
rellla3 has quit [Remote host closed the connection]
tzafrir has quit [Ping timeout: 252 seconds]
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
<mnemoc> i don't think the bsp supports A20 yet
NermaN has quit [Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/]
<ganbold> mnemoc: is sunxi-3.4 the latest src?
<JohnDoe_71Rus> mnemoc: kernel for linux compiled
<mnemoc> stage/sunxi-3.4 has the latest changes of the "legacy" (but full featured) sunxi kernel, like gmac support
<mnemoc> but it needs love to properly support the 3 different *mii
n01 has joined #linux-sunxi
n01 has quit [Ping timeout: 265 seconds]
n01 has joined #linux-sunxi
BluesBoy has joined #linux-sunxi
deasy has joined #linux-sunxi
prasannapete has quit [Quit: prasannapete]
AreaScout has joined #linux-sunxi
FR^2 has joined #linux-sunxi
y0g1 has quit [Quit: leaving]
y0g1 has joined #linux-sunxi
vicenteH has quit [Ping timeout: 246 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
BJfreeman has quit [Quit: had a good time]
enrico_ has joined #linux-sunxi
_massi_ has joined #linux-sunxi
adb has joined #linux-sunxi
<arokux> mnemoc: no, I do not know anybody
<mnemoc> ok
<mnemoc> thanks =)
y0g1 has quit [Remote host closed the connection]
<oliv3r> good morning all
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
Jerry_ has quit [Ping timeout: 250 seconds]
tzafrir has joined #linux-sunxi
prasannapete has joined #linux-sunxi
popolon has joined #linux-sunxi
[1]Jerry has joined #linux-sunxi
y0g1 has joined #linux-sunxi
<arokux> what are the last news guys?
y0g1 has quit [Client Quit]
y0g1 has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<JohnDoe_71Rus> arokux: I almost started rt3072. but we do not talk about it.
<arokux> JohnDoe_71Rus: what is this?
<JohnDoe_71Rus> usb wifi.
<JohnDoe_71Rus> under android cubieboard2
<hno> JohnDoe_71Rus, why no talk?
wens has quit [Quit: Lost terminal]
wens has joined #linux-sunxi
<JohnDoe_71Rus> because it is an android and lichee kernel
<[7]> hm... xz kernel decompression should take like 1-2 seconds, but it takes 20. gzip takes 6 seconds, while it should be much faster. and lzo, which should be almost instant, didn't finish within a minute. now what's wrong there...
<[7]> maybe the caches are off? but I guess they should be off when uboot hands over, and then be enabled by the kernel before it decompresses itself?
<torbenh3> iirc in u-boot the datacaches have been turned off, at some point, because of gmac, or somthing.
<[7]> I'm using some oddball lichee uboot, so I'd be fairly certain that this is the culprit... I'm just wondering what it might be doing wrong.
<torbenh3> well... i can only speak for sunxi u-boot. dunno anything about lichee...
<[7]> the thing is that IIUC the bootloader is supposed to turn caches off before handing over
<[7]> so it can't be doing much wrong there
<torbenh3> yup.
jinzo has joined #linux-sunxi
jinzo has quit [Changing host]
jinzo has joined #linux-sunxi
<juanfont> i've jsut tried vdpau on a A20. it works pretty nice
<oliv3r> libv: LOL but my desktop ix x86 ;)
<[7]> hm. the kernel startup code enables caches very early, there's just no way how this couldn't work, at least if the cp15 processor ID is correct
<[7]> but that's not something uboot could be messing with
<libv> oliv3r: is your desktop a geode?
<libv> oliv3r: did you really think you could get away unnoticed with playing with x86 hw?
<libv> oliv3r: this is the internet, somebody is always watching you
<maz> [7]: decompression is slow because you need to turn on the SMP bit in the ACTLR while in secure mode.
<libv> oliv3r: and if you have certain cravings, like for instance a craving for playing with coreboot on geode, then you will be found out
<maz> [7]: see the A7 TRM for details.
<[7]> maz: I guess there's a reason that the code isn't doing that?
<maz> [7]: other than ignorance, no.
* [7] wonders why they'd accept 5-10 seconds boot delay for no reason
<maz> [7]: A7 has a hardware dependency between SMP and caches, and it is the only one to behave like this.
<[7]> hm... is that init code run in the correct mode to set that bit? i.e. secure SVC or whatever?
<maz> [7]: well, apparently nobody can be bothered to read the documentation. this issue has cropped up several times.
<maz> [7]: secure SVC or monitor mode are required to access the ACTLR. I'd expect u-boot to run in that mode on the AW platforms.
<[7]> ...but not the kernel init code?
<[7]> or that as well?
<[7]> so IIUC I can just turn that on, and later code that brings up the second CPU will take care of temporarily disabling it again if required?
<maz> No. kernel should really run in non-secure. This is a firmware setup, and the kernel is best left alone.
<[7]> so the real problem is NSACR.NS_SMP being 0?
<maz> [7]: no. the problem is ACTLR.SMP.
<[7]> well, if that can only be set from within the secure world, and the kernel is running in the non-secure world, but the kernel has to bring CPUs up/down, this might be a problem?
<maz> [7]: that's why CPU up-down should run on the secure side. see the PSCI patches I've posted two weeks ago.
<[7]> what's the downside of allowing non-secure mode to control the SMP bit?
<maz> [7]: it kills the firmware running on the secure side, and I'll nack any patch touching that.
* [7] wonders what is even running on the secure side on these systems
<[7]> so, in your opinion, ACTLR.SMP should just be enabled by uboot and then left alone?
<hramrach> there was some work to make this correct for sunxi u-boot
<maz> [7]: yes. that's the recommended setup.
<hramrach> if you use lychee then you might still have something odd
<maz> hramrach: sunxi-u-boot has some code to deal with that indeed.
<hramrach> which might happen to work with whatever kernel was shipped with the device but not with fresh sunxi kernel
<hramrach> so if you really want to run lychee I suggest finding and cherry-picking the commits that fix this
<[7]> for uboot or the kernel?
<hramrach> u-boot
<hramrach> and if you get it working push a branch to github or somewhere :)
<maz> [7]: the kernel as it is runs perfectly fine, full speed, and in non-secure mode. no patch required.
<[7]> maz: I'm not fully understanding why the kernel doesn't have a problem with caches, while the decompressor does, but the kernel isn't even supposed to have enough privileges to fix it after decompressing
<hramrach> the kernel probably has the problem still
<[7]> it doesn't seem to be *that* sluggish though
<hramrach> it's just that it's very obvious with the decompression
<hramrach> either way the correct fix is to make u-boot set up the cache
<[7]> i.e. most android services start up in the time that it takes to decompress 2MB of gzip data. feels odd.
<hramrach> or smp bit or w/e
<maz> [7]: look at the kernel code. The kernel sets the SMP bit. If it is running in non-secure mode, that write will be ignored. So in your setup, only the decompressor is affected.
<maz> [7]: but if you're running non-secure, you absolutely need the bootloader to set the SMP bit from secure, before switching to HYP.
<maz> [7]: and that on both CPUs.
<[7]> hm, setting it on the second CPU might be tricky
<maz> [7]: this is why I'm working on getting PSCI going.
<[7]> this seems like it's only getting set on CPU0 by u-boot-sunxi?
[1]Jerry has quit [Read error: Connection reset by peer]
<hramrach> Vertex_: BT worked for me with the shipped firmware. Try some cubietech kernel I guess
<torbenh3> hramrach: how did you load the firmware ?
<torbenh3> is the BT firmware separate from wifi ?
<hramrach> torbenh3: I did not. I can send you the nand image if you want ;-)
<hramrach> but it's android
<oliv3r> mnemoc: bsp does support A20 ;)
<[7]> hm, enabling SMP ends up with a null pointer oops ~4 seconds into boot :/
<[7]> but XZ decompression is like a second now
<oliv3r> libv: ohh geode! yes I have 5 old thinclients, I converted one as a mpd box so I have my own radio @work ;)
<[7]> hm, another attempt didn't oops.
<oliv3r> libv: i wanted to get coreboot on it, but I got it running atm so leaving it 'as is' for now. i haven't hacked on it, I promisse ;0
<[7]> ok, back to fixing this vsync thing
<libv> oliv3r: leave the dark side! come back to sunxi!
<oliv3r> anyay, i'll go be sadistic again and document some more of the BROM, ccause it's fun to read ASM
<oliv3r> i a huge ASM noob, i wanna play with it, so translating is good practise
<JohnDoe_71Rus> oliv3r: do you see my post about kernel?
<oliv3r> JohnDoe_71Rus: i saw something android failing
printallthething has joined #linux-sunxi
<oliv3r> Can't find default configuration "arch/arm/configs/sun7i_wing_defconfig"!
<oliv3r> but we don't have sun7i android config yet
<oliv3r> it hasn't been 'made' yet
<oliv3r> so that's why it fails
<mnemoc> oliv3r: great!
<JohnDoe_71Rus> oliv3r: think you add "wing"
<oliv3r> feel free to diff sun7i_defconfig and sun4i_nuclear_defconfig and create sun7i_wing_defconfig and submit it via the ML; we do nee done
<oliv3r> JohnDoe_71Rus: yeah that's the official code name for sun7i android, but we don't have android kernel for sun7i yet, wel no defconfig
geecko has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
geecko has quit [Ping timeout: 253 seconds]
Brod_ has joined #linux-sunxi
hurtigbuffer has joined #linux-sunxi
jelly-home has quit [Ping timeout: 240 seconds]
Brodomir has quit [Ping timeout: 240 seconds]
hurtigbuffer is now known as jelly-home
Tartarus has joined #linux-sunxi
geecko has joined #linux-sunxi
<hramrach> JohnDoe_71Rus: or use the config from sdk .. somebody was saying earlier that it differs from sunxi config a lot
<[7]> hm, again a null pointer dereference (offset 0x24) here: [ 4.790479] [<c0344a44>] (tp_do_tasklet+0xb0/0xc50) from [<c003b4a8>] (tasklet_action+0x80/0x11c)
<oliv3r> [7]: pastebin a little more details ;)
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<torbenh3> hard to say, whats broken, without knowing which tasklet is firing... although its very likely, that the irq, that just fired, was the one activating the tasklet... although that should have been the serial irq, that printk was waiting for...
rellla has joined #linux-sunxi
<[7]> torbenh3: this happens like once in 3 boots right now. and if it happens, it happens ~3-4 seconds into the boot, but never later
<[7]> I can upload the vmlinux file if that's of any help
<torbenh3> no it isnt
<torbenh3> you have to sprinkle a set of printk into the right places and hope, that it doesnt magically fix your problem...
<[7]> could this be somehow related to the fact that I have enabled 7 uarts?
<[7]> allwinner's 3.3 consistently paniced if more than the first 4 uarts were enabled due to a really dumb bug
<[7]> I guess that's fixed in 3.4 though
<torbenh3> just find out, which tasklet is executing there ?
BluesBoy- has joined #linux-sunxi
<torbenh3> oh. its the ts
<oliv3r> [7]: either fex error or sun4i-ts driver error, i would put my money initially at a fex error
<mripard_> Turl: hey!
<mripard_> Turl: stop undoing my corrections :)
BluesBoy has quit [Ping timeout: 272 seconds]
BluesBoy- is now known as BluesBoy
<oliv3r> [7]: if you enable all 7 uarts, which is possible, are you sure you disabled all other devices using the same uart ports?
<[7]> I'd think so
<[7]> could have missed something though
<oliv3r> [7]: tripple check that, uart_para1 is disabled btw, but if you enabled all uarts, tripple if not quad check you disabled all other muxes
<[7]> yes, uart_para1 is the only one that isn't used
<[7]> 0/2/3/4/5/6/7 are on
<Turl> mripard_: ah, I got confused when you moved the link up one section :p
<Turl> yay for wiki logs :)
<mripard_> Turl: you're adding wrong stuff quicker than I can fix it :)
<mripard_> the timer fix is in 3.13, not 3.14
<mripard_> and the SID driver got merged in 3.13
<mripard_> not only the DT
<mripard_> the DT and the driver
<[7]> oliv3r: searching in the fex file for the pin numbers mapped to the uarts should be sufficient, right?
<[7]> or could there be anything hiding?
<oliv3r> [7]: in theory ;)
<Turl> mripard_: didn't greg merge the driver for 3.12?
<mripard_> Turl: he said he would
<mripard_> but he didn't :)
<oliv3r> he didn't though
<Turl> mripard_: we need to remove it from the 3.12 list then :p
<[7]> well, there's a "clash" between [uart_para0] and [uart_para]
<[7]> as in uart_debug_tx == uart_tx of uart_para0
<[7]> but as that's the physically same thing, I'd expect that this should work
<oliv3r> mripard_: what should we do with sata, clean it up for submission now and start talking about a rewrite of ahci_platform, or rewrite the whole thing and do a big patch?
<[7]> or should I just turn uart_para0 off in that case?
<[7]> another one clashes with spi_mosi of spi1_para, but that has spi_used=0, so it should be safe as well (and I don't think SPI is even compiled into that kernel)
<Turl> mripard_: should be all fixed now :)
<[7]> oh, typo on uart4
<[7]> tx=rx. hmm.
<oliv3r> [7]: that's ok i think, as uart_para is for boot0/boot1 and uart_para0 is for the kernel
<[7]> the rest doesn't clash, as far as I can tell
<mripard_> just sayin' :)
<oliv3r> [7]: then i don't know :(
ganbold_ has joined #linux-sunxi
<mripard_> oliv3r: I don't know
<Turl> mripard_: mea culpa then :) it's fixed now in any case
<[7]> let me flash a fix for uart4
<mripard_> if you can come up with a different name for the sunxi_ahci.c driver name, and the one in platform_device_id in ahci.c, you can submit it
<mripard_> it's a big pile of crap, but I think it would be mergeable
<mripard_> since the others have been merged that wa
Quarx has joined #linux-sunxi
<oliv3r> and make mention in the cover sheet that talk should start about rewriting the pile of crap then :)
<oliv3r> mripard_: i'll probably use something sata in the name then
<mripard_> oliv3r: sunxi-sata for the driver name would make sense.
<oliv3r> right, i'll do that, so drivername IN sunxi_ahci.c -> sunxi_sata, dt prob needs updating and pdi in ahci.c; rgr
<[7]> [ 53.048426] [ccu-err] clk_enable: invalid handle
<[7]> during resume of i2c/twi interfaces 3 and 4
<oliv3r> while I also prefer the better long term solution, it does require a lot of work, and having it merged in its current state does sound sensible to me
<[7]> then it panics due to axp209 trouble
<oliv3r> well you need atleast 1 t2c interface to talk to the axp
<mripard_> oliv3r: you don't need to change the compatible
<oliv3r> mripard_: ok better
<mripard_> just the driver name, at the bottom at the file
<oliv3r> DRV_NAME ;)
<mripard_> the compatible is fine :)
<oliv3r> got it
<oliv3r> so it's kinda a dirty hack :p
<mripard_> (keep in mind that we won't be able to change the compatible afterwards, while we can refactor all those names, and stack and everything all we want)
<mripard_> so I'd better stick with the "real" compatible.
<oliv3r> yeah i agree strongly
<oliv3r> right, i'll make that happen today and test it
<oliv3r> 2 1/2 hrs left in the day should be possible
<oliv3r> i'll lve my asm BROM lessons for today :)
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<Turl> yay sata :)
geecko has quit [Ping timeout: 240 seconds]
<oliv3r> yeah it works! (tm)
<rellla> sata should work on A20? i didn't get it to work :(
<Turl> $PI is going to be an interesting release if we can get sata, gmac et al working :)
<libv> hramrach: thanks for the wiki sanitization work
<[7]> Turl: I looked into that vsync problem
<Turl> hi [7]
<[7]> basically added all code that had this specific comment
<[7]> which worked somewhat well, the boot animation is smooth now
<Turl> [7]: nice :)
<Turl> [7]: please submit a patch to the list with the changes
<[7]> I also checked it in a bit more detail, and it seems to be consistent, no other references in the code base to the new variables etc.
<[7]> however it just freezes the display after the boot animation exits in like 90% of attempts
<[7]> in 10% I see the lock screen, but it locks up shortly after, before I manage to unlock it
<oliv3r> rellla: what kernel
<Turl> may be unrelated, did you check logcat?
<[7]> lots of chatter in logcat, but nothing really interesting
<rellla> oliv3r: latest stage/sunxi-3.4
<oliv3r> rellla: should, but not sure
<Turl> [7]: no buffer dequeuing failures or other ugly stuff?
<oliv3r> i'll double check later if i have time, otherwise tomorrow if you remind me
<oliv3r> Turl: $PI? SPI? $berry Pi?
<Turl> oliv3r: linux 3.14 ;)
<rellla> oliv3r: i prepared my rootfs on sata-ssd with CubieboardA10 but connecting and mounting it on CubieboardA20 ends up with a hangup. i'll post dmesg later...
<[7]> Turl: hm. now that happened to be one of the very rare attempts where it actually displayed a lock screen, and there I got lots of these dequeuing errors
<oliv3r> Turl: whatdid you mean with $PI
<[7]> however I don't think I got them when it locked up earlier
<oliv3r> ohhhh
<oliv3r> pi
<oliv3r> ${PI}
<oliv3r> i was thinking pi/rapsberrypi/LIME :p
<[7]> E/BufferQueue( 95): [FramebufferSurface] dequeueBuffer: min undequeued buffer count (1) exceeded (dequeued=3 undequeudCount=0)
<[7]> E/ ( 95): void __egl_platform_dequeue_buffer(egl_surface*):1188 [EGL-ERROR] failed to dequeue buffer from native window (0x416ed638); err = -16, buf = 0x40609ff0
<Turl> oliv3r: :p
<[7]> that kind of thing
<oliv3r> 3.1415 :p
<Turl> [7]: that's because the mali stuff is a bit too old, let me look up a patch for you
<Turl> [7]: apply that on frameworks/native/
<Turl> and add BOARD_EGL_NEEDS_LEGACY_FB := true on device/softwinner/whatever/BoardConfig.mk
<[7]> hm... just curious, what's holding us back from just using newer mali drivers, e.g. the ones that AW used in their 3.3 stuff?
<Turl> lack of blobs for all the platforms
<Turl> we have r3p0 for all the things; there's r3p2 ones for linux/x11 too from what I recall
<Turl> what's allwinner using on the sdk these days?
<[7]> let me check what's in my working kernel
<[7]> looks like r3p2
<oliv3r> mripard_: i assume that we still need a sub-entry for sunxi_ahci in the KConfig? (in the future platform_ahci is probably enough, just not yet?)
<Turl> ssvb: ^^
<oliv3r> Turl: do you use your own sunxi_full_defconfig?
<mripard_> oliv3r: yep
Taduro has quit [Ping timeout: 246 seconds]
<oliv3r> mripard_: excelletn
rz2k has joined #linux-sunxi
<Turl> oliv3r: from time to time, when I break my config
<oliv3r> Turl: no modules enabled, udev not automounted :)
<Turl> why would I want modules?
<Turl> and what do you mean by udev? devtmpfs ftw :)
<oliv3r> erm that
prasannapete has left #linux-sunxi [#linux-sunxi]
<oliv3r> and the kernel won't compile with defconfig and modules disabled it cries and says 'modules disabled you bitch'
<Turl> CONFIG_DEVTMPFS=y <- what's wrong with it?
<Turl> oliv3r: huh?
<oliv3r> one option after that
<mripard_> Turl: you need CONFIG_DEVTMPFS_AUTOMOUNT as well
<mripard_> well
<mripard_> you don't *need* it
<mripard_> but it's convenient
<Turl> mripard_: my buildroot mounts it already I think
<Turl> I mean, my system works :p it must mount it
<mripard_> buildroot by default puts static device files
<Turl> oliv3r: Image arch/arm/boot/uImage is ready
<Turl> oliv3r: with the config
<mripard_> Turl: hmm, ok.
<Turl> mripard_: besides
<Turl> │ This option does not affect initramfs based booting, here │
<Turl> │ the devtmpfs filesystem always needs to be mounted manually │
<Turl> │ after the roots is mounted.
<mripard_> Turl: aaah, yes.
<Turl> (nice typo there if anyone wants to score a patch :))
\\Mr_C\\ has joined #linux-sunxi
Md has joined #linux-sunxi
<oliv3r> Turl: yeah static dev files!
<oliv3r> Turl: anyway, it's a sane default ;p
<oliv3r> Turl: i do admit I build out of tree using the BSP
<Turl> oliv3r: do you want to fix the typo? :p
<oliv3r> i haven't even spotted it yet :p
<Turl> oliv3r: "after the roots" -> "... rootfs"
<oliv3r> oh i thought it was plural root :p
<Turl> then it would be roots are :p
<Turl> but by definition there's only 1 root
<oliv3r> i know :p
<oliv3r> you found it you fix it :p
<Turl> ok
<oliv3r> Turl: anyway, the reason i mentioned automount devtmpfs is because i thought it would make the kernel more verbose
<oliv3r> Warning: unable to open an initial console.
<oliv3r> because of that
rz2k has quit [Ping timeout: 246 seconds]
<oliv3r> mripard_: uh oh, sunxi-sata went BOOM
adb has quit [Ping timeout: 252 seconds]
<plaes> o_O
<mripard_> it's a gimmick :)
<hno> Turl, is there really only one root? Quite often have more than one,..
<hno> but yes.
cubear has quit [Quit: Leaving]
<oliv3r> anybody else hearing a high-pitched noise comming from their CT?
<oliv3r> it's very feint
rz2k has joined #linux-sunxi
<Turl> oliv3r: ok, typo fix sent
Gerwin_J has joined #linux-sunxi
<oliv3r> Turl: \o/
<wens> Turl: still in the process of clarifying stuff with the maintainer of stmmac...
<mripard_> wens: could I be in cc of these mails ?
<wens> mripard_: sure, I'll add you in the next reply, if any?
<oliv3r> wens: it would also be kind to cc linux-sunxi :)
<mripard_> wens: great thanks :)
<wens> oliv3r: sure :)
<Turl> yay hans got mmc working
<Turl> :)
<mripard_> Turl: did he ?
<mripard_> cool
<wens> mripard_: saw srinivas asking Dave whether he would take the series or not
wingrime has joined #linux-sunxi
<oliv3r> mripard_: i'm a little confused as to what needs to be changed, because when I change it, it stops working, but currently it works
<Turl> mripard_: the last bug turned out to be the interrupt type
<oliv3r> hmm, pins look wrong, lemme double check
<mripard_> oliv3r: how is it "not working" ?
<oliv3r> this works just fine
<oliv3r> this patch works, but the name is still sunxi-ahci
<mripard_> oliv3r: hmmmm, I don't follow you here
<mripard_> Turl: :S
<oliv3r> well you said we should rename it
<oliv3r> but it allready works without the rename, so not sure why we need to rename it
<mripard_> there's no sysfs warning, no double probe, no nothing ?
<oliv3r> i did rename it to sunxi-sata, removed it from platform_device_id ahci_devtype[]; (left it in ahci_type and ata_port_info) but then it goes boom with the double probes
<oliv3r> yeah its' fine
<[7]> Turl: with that patch it seems to be stuck at the boot animation...
<[7]> logcat repeatedly says this:
<[7]> I/ServiceManager( 495): Waiting for service media.audio_policy...
<[7]> I/ServiceManager( 495): Waiting for service media.player...
<mripard_> oliv3r: but you don't have to remove it from ahci_devtype
<mripard_> oliv3r: then, you are lucky :)
<hramrach> mripard_: hansg did something about the double-probe
<oliv3r> mripard_: the git i pasted earlier is the working code as it is now
<mripard_> oliv3r: then it's just that you are lucky, and that ahci_platform.c is registered before sunxi_ahci.c
<oliv3r> okay
<mripard_> hramrach: this was about probe deferral, wasn't it ?
<oliv3r> so it still needs to be fixed :p
<hramrach> mripard_: yes, something like that.
<wens> oliv3r: doesn't look like it would do a double probe in the code you posted
<oliv3r> now I'm confused :D
geecko has joined #linux-sunxi
<[7]> hm, missing cedar libs...
<[7]> can I somehow just get rid of cedar altogether easily?
<wens> imx53 uses ahci in platform_device_alloc(), this the rename you were refering to?
<oliv3r> [7]: sure, just disable the kernel module (and reclaim the memory)
<Turl> [7]: no crashes before that?
<hramrach> anyone knows where to get usb to serial ttl adaptors?
<oliv3r> hramrach: i get them cehap from DX
<hramrach> dx has tons but no specs
<mripard_> wens: no, imx6 uses ahci.
<mripard_> imx53 uses imx53
<hramrach> plus the one that came with CB leaks current somewhere and makes the HDD attached to CB spin up when the CB is powered down in some mysterious way
<hramrach> so I would like to avoid that
<Turl> hramrach: olimex sells them if you don't want dx/ebay
<Turl> hramrach: also cubietech does
<libv> hramrach: i just killed mine, and i am waiting for amazon to deliver
<oliv3r> hramrach: i use these, work like a charm
<libv> so today you can pretty much get them anywhere
<libv> things really have changed in the past few years
<wens> oh, device names and driver names are different there
<oliv3r> oh that's how i got confused over imx53 and imx-ahci, i wasn't sure what exactly you ment there ;)
<oliv3r> i'll relook as that's what I possibly have done wrong myself, assume that imx53 and imx-ahci are the same
<wens> oliv3r: apparently, neither did i :p
<notmart> hi all, sorry if is the millionth time somebody asks this question...
<notmart> i have an a20 board (eoma68) and i am trying to enable opengles following this http://linux-sunxi.org/Binary_drivers
<oliv3r> hramrach: the usbuart doesn't leak power, the cubieboards miss a resistor/diode on the pins; it's a layout bug
<wens> oliv3r: i thought they did, from the rx pin?
<mripard_> oliv3r: other USB->serial are working fine :)
<oliv3r> mripard_: you mean yours doesn't leave the power led on when you disconnect the power?
<mripard_> oliv3r: so I guess it's a combination of the USB->UART leaking power, and the cubieboard missing a diode
<mripard_> oliv3r: yep.
<oliv3r> wens: i thought the bug was on the board, not the uart adapter side
<wens> EOMA-68 mentioned that boards should have buffers in front of the UART?
<notmart> but so far no luck, i was wondoering if am doing something obviously wrong... (fbturbo x11 driver works, but any opengles app fails printing error 0x3005 on stderr)
<Turl> mripard_: yours probably has a long cable
<oliv3r> i have 3 diff uarts and they all 'leak
<mripard_> Turl: Kevin asked Tom about it
<wens> mine sometimes does, sometimes doesn't
<mripard_> (Kevin Hilman)
<libv> notmart: which egl apps?
<mripard_> and Tom's answer was "change the USB->uart adapter"
<hramrach> so any PL2303 or CP2102 should work at 3.3v?
<mripard_> and it acutally did the trick.
<libv> hramrach: just find one that is near you, and post the link here
<notmart> libv: one called glmark2-es2 taken from an ubuntu image where it works and some Qt apps (with qt built to use qgles)
<libv> notmart: why "taken from an ubuntu image"
<oliv3r> mripard_: so ata_port_info struct is the wrong way? because it looks like that's the only place those port options are set?
<libv> notmart: why not just apt-get install it?
rz2k has quit [Ping timeout: 248 seconds]
<hramrach> it has no specs whatsoever
<hramrach> except it uses PL2303HX as if that's supposed to say everything?
<notmart> libv: i am working on a Mer image
<Md> hramrach: it says "5V" on the page, so it's not good for the cubieboard
<libv> hramrach: look on to the next one
<Md> actually the wiki is not very clear about this. it should not say "TTL serial", since TTL implies 5V level
<notmart> but, if i try on the board the image http://www.gplsquared.com/eoma_boot/cubie_eoma_ubuntu_13_04_3d.bin.xz mentioned on http://www.gplsquared.com/eoma_boot/eoma_boot.html opengles does work
<libv> notmart: have you tried running the test application as explained in the binary drivers howto?
<hramrach> Md: that's probably just the 5V from USB wired through to the connector
<libv> Md: improve it.
<libv> Md: it's a wiki
<notmart> libv: no, i guess i have to modify the package i did of the binary drivers to build and package the test..
<Md> libv: you have a point...
<notmart> but i can do that yes
<mripard_> oliv3r: I really don't get what you don't get :)
<notmart> does it have more debug output on what is actually going wrong?
<hramrach> the Nokia one is rather expensive compared to other DX offerings and you have to cut the wire :s
<oliv3r> mripard_: i don't get what i have to rename and what needs to be stripped :)
<libv> notmart: why not just build it natively?
<mripard_> oliv3r: it shouldn't be done that way, but if you don't want to refactor the thing right now, it's the only wayp.
<libv> notmart: there is no point in packaging it
<oliv3r> mripard_: that I do get :D
<notmart> yeah, i can try that too ;)
<oliv3r> mripard_: and I agree with that too
<hramrach> the wiki says 3.3V
<libv> hramrach: this dx.com thing you posted shows a load of other uart devices
<Md> hramrach: if it does not say 3.3V then you should assume that it is real TTL, i.e. 5V
<mripard_> oliv3r: the driver name to something different than what you have in platform_device_alloc
<oliv3r> mripard_: for example https://github.com/oliv3r/linux/commit/356c86bef399557a10734ca2073eeac4de7e65bd#diff-68448d89ba2d5e1e2b1b0bae805304c6R31 here we have 3 sunxi additions, getting rid of ahci_type because of the .name clash?
<mripard_> you don't have to touch anything in ahci_platform.
<libv> hramrach: they all come with 5 pins, gnd, rx, tx, 5v ... and 3v3
<hramrach> libv: that's somehow autogenerated based on what you viewed
<oliv3r> mripard_: ohh ok you said 'driver name below'
<libv> hramrach: ah, right
<oliv3r> so i wrongfully assumed you ment in platform_driver struct
<mripard_> oliv3r: well, yeah.
<mripard_> this
<libv> hramrach: what part of http://linux-sunxi.org/UART#UART-USB_dongle did you fail to read?
<oliv3r> now it's becoming way more clear :)
<oliv3r> the 'below' I took all the way ;)
<libv> "Just search for "CP2102" or "PL2303" on your favourite online retailer or auction site."
<libv> and you will be flooded with useful matches.
<hramrach> libv: I read it. It does not make it obvious how to tell the adaptor has 3.3V level
<hramrach> presumably that's up to the seller to specify
<libv> hramrach: 5 pins, gnd, rx, tx, 5v ... and 3v3
<Md> hramrach: if it says 3.3V it is 3.3V, if it does not and just says TTL then you can safely assume that it is 5V
<mripard_> oliv3r: I don't understand what you mean.
<oliv3r> mripard_: sata-ahci is used twice in the code, once for the driver .name in the main platform_driver struct, and once in the platform_device_alloc
<oliv3r> mripard_: and i think you reffered to both seperatly
<libv> hramrach: you do not tend to connect the 5V/3V3 lines, unless you want to incur damage
<libv> hramrach: but the module then is 3V3 compatible and tends to just work
<oliv3r> and if it only says serial, it may be upto 24 V!
<Md> libv: what? no, the level of the TX line could be 3.3V or 5V
<mripard_> oliv3r: do you get how your code work ?
<libv> Md: hasn't killed anything here yet.
<oliv3r> Md: but aren't 5V parts often 3.3V tolerant/compatible
<oliv3r> mripard_: you confused me!
<[7]> oliv3r, Turl: libmediaplayerservice.so seems to require libCedarX.so
<Md> libv: maybe your board is 5V tolerant? but the adapters are definitely different
<[7]> confusingly enough it did get further before the surfaceflinger patch
<oliv3r> [7]: ohh android!
<oliv3r> mripard_: but it's ok, it works now with the rename :)
<libv> Md: ok, if you want to make hramrachs life difficult, then you can do so, on your very own.
<oliv3r> mripard_: I confused me more.
<oliv3r> mripard_: i missread your string
<libv> Md: so feel free to fully handhold hramrach through his uart module buying process
<oliv3r> mripard_: http://irclog.whitequark.org/linux-sunxi/2013-12-02#5743296;alloc you said DIFFERENT from i overlooked the word different :)
<oliv3r> mripard_: my appologies
<Turl> [7]: any specific reason why you lack that last so?
<mripard_> oliv3r: that's fine, don't worry :)
<hramrach> this page https://www.adafruit.com/datasheets/PL2303HX.pdf says that the PL2303 should work with 3.3~1.8V
<[7]> Turl: because I didn't copy it, and didn't think that it was really needed. flashing an image with that file right now
<[7]> but if possible I'd rather get rid of that stuff completely and free up the RAM, that board won't be doing video decoding anyway
<hramrach> when you don't have extra circuitry to change the voltage
<oliv3r> mripard_: so when you said imx6 uses ahci directly, and imx53 does not, you did mean though that imx53 uses platform_ahci right?
<oliv3r> mripard_: e.g. imx53's ahci is similar to sunxi's
<oliv3r> mripard_: so if I understand correctly, we load both drivers and half of one driver does the init etc (sunxi_ahci) followed by platform_ahci which takes care of the rest?
<mripard_> oliv3r: yes
<oliv3r> and that's why it's so ugly
<oliv3r> but not possible otherwise now, got it
<Md> hramrach: see table 9.3: this chip provides a 3.3V, 5V tolerant serial
<oliv3r> and platform_device_add actually invokes platform_ahci from sunxi-sata; ok now we are on the same level :p
<[7]> Turl: hm, it's somewhat working now
<oliv3r> i'll split it up into seperate patches now and start the review, because there's other things that need to be reviewed and discussed
<[7]> however the touchscreen is doing nonsense
<Turl> [7]: probably just in need of calibration
<libv> Md: so the wiki page should read PL2303HX instead of just PL2303
<[7]> no, it's acting totally weird. as if it was a laptop touchpad, not a touchscreen
<Turl> [7]: yeah, calibration
<[7]> i.e. it ignores the absolute position, but only seems to track relative movement
<hramrach> HX is a variant currently in use
<[7]> and that with the x axis flipped
<[7]> with the allwinner image it was just the flipped x axis, but not that relative tracking
<Md> libv: yes, because the PL2303 is a 5V chip
<Turl> [7]: you need an idc file matching your touch thing's name
<[7]> no idea, it's a simple 4-pin resistive panel
<Turl> [7]: run getevent on a shell, it should print all the device names
<libv> Md: ok, adjusting (i have only used CP2102 so far)
<[7]> anyway, I also have a bigger problem: it doesn't come back from sleep
<[7]> and the LCD flashes white while entering sleep
<libv> Md: the PL2303 non-HX modules come with only 4 pins as well
<[7]> the new disp driver had huge amounts of changes wrt. power management
<Turl> [7]: ouch
<libv> so as soon as PL2303 is advertised, and 5 pins are visible, things should be ok
<[7]> or rather I don't know if that's new code, or nonsense code that was just removed on the sunxi side
<[7]> I didn't check the history, just diffed it
<Md> libv: I expect that 5 pin connectors have CTS/RTS lines
<Turl> Md: the ones I've seen have gnd, tx, rx, 3v3 and 5v
<hramrach> libv: Md actually, if you look at table 5.2 you see that the serial port level is 1.8V~3.3V depending on supplied power but there is no option to use 5V other than with extra components
<oliv3r> 5V because USB is 5V so it's a cheap and easy way to also have that
<[7]> seems like something's wrong with i2c resume
<libv> wiki adjusted accordingly.
<Nyuutwo> oliv3r: you get 5V power supply but you need 3v3 LDO for USB transmission
<Turl> [7]: looks like it
<Md> it is often 5V because this was the voltage of original TTL chips well before USB was invented. if you care about the history, have a look at wikipedia. nowadays it is more common to use a lower voltage
<oliv3r> Nyuutwo: aye
<Turl> bbl
<Nyuutwo> Md: real ttl works with 3V3 logic
<[7]> hm, but why does it only fail for 2 out of 4 TWI interfaces...
<libv> is this section now clear enough? http://linux-sunxi.org/index.php?title=UART#UART-USB_dongle
<Nyuutwo> you only need resistive divider for 5->3V3
<libv> now that the search terms are bold, and the formal recommendation is on a separate line, will it correctly and succinctly help those who are unable to RTFM?
<Nyuutwo> but for CMOS (in which nowadays everything is) it is not reiable
<Md> Nyuutwo: "real TTL" uses 5V, this is not really a matter of opinions. still, modern circuits will often work with a 3.3V level as well
<hramrach> there is no such thing as PL2303
<oliv3r> mripard_: i guess your not very enlgihtened about the ahci stack either; since this will need some discussion on the ML anyway, but do you know if our ahci controller has its own dedicated DMA? see https://github.com/oliv3r/linux/blob/0184f6e37fb3ba7641b5edf3ede9477e09f6c5f8/drivers/ata/libahci.c#L573 this change, which obviously isn't multiplatform, but not sure how we'd want to handle that generally other then move it to ahci_enable_dma() and only c
<libv> hramrach: ...
<libv> great how such simple things unearth.
<libv> we'll make great pets.
<Nyuutwo> hramrach: i have one of them connected to my PC now
<Nyuutwo> AFAIR PL2303 has pin VCCIO which you connect to 5V or 3V3(LDO inside chip)
Taduro_ has joined #linux-sunxi
Taduro_ has quit [Read error: Connection reset by peer]
<hramrach> depends on the chip variant. Prolific makes like half dozen chips PL2303something which differ in package and output voltage capability
BluesBoy has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D]
Taduro_ has joined #linux-sunxi
shineworld has joined #linux-sunxi
geecko has quit [Ping timeout: 272 seconds]
<[7]> Turl: even with your patch:
<[7]> E/BufferQueue( 95): [FramebufferSurface] dequeueBuffer: min undequeued buffer count (1) exceeded (dequeued=3 undequeudCount=0)
<[7]> E/ ( 95): void __egl_platform_dequeue_buffer(egl_surface*):1188 [EGL-ERROR] failed to dequeue buffer from native window (0x41112570); err = -16, buf = 0x40579ff0
HeHoPMaJIeH has quit [Remote host closed the connection]
shineworld has left #linux-sunxi ["Leaving"]
Vertex_ has quit [Quit: Page closed]
<[7]> blargh. the i2c driver just doesn't support ports 3 and 4 at all
<Turl> [7]: did you add the boardconfig flag?
<[7]> Turl: i2c-sunxi.c is just hardwired to ports 0/1/2
<[7]> will read past the end of some arrays if a higher port is in the fex
<Turl> [7]: that's A10 and the like don't have that many i2cs, might be from that
* [7] wonders why references to i2c0/1/2 turn up in the disp code :/
<Turl> [7]: EDID is done via i2c
<[7]> that really shouldn't mess directly with clock gates from there...
<[7]> a closer look suggests that this is probably dead code though
<[7]> Turl: regardig the boardconfig flag: i patched it the hard way
<[7]> i.e. didn't ifdef it at all
<[7]> the patch wouldn't have applied anyway
<Turl> [7]: with the right branch? it had an ifndef I think
<[7]> my file already included the header and had just this line at the other hunk:
<[7]> ANativeWindow* const window = mNativeWindow.get();
<[7]> which I just replaced with this:
<[7]> ANativeWindow* const window = new FramebufferNativeWindow();
<[7]> the mNativeWindow = new Surface(mDisplaySurface->getIGraphicBufferProducer()); line wasn't there in the first place
<Turl> maybe aw patched it for you already? :p
<[7]> that AW tree came with mali r3p2
<Turl> [7]: talk with ssvb, it may be time to upgrade then
<[7]> actually I'd prefer to keep r3p2 anyway :)
<[7]> but of course those 3.3 modules won't work with sunxi-3.4
<Turl> [7]: I believe ssvb already brought up r3p2 kernel wise, but it wasn't merged yet due to blob availability
<Turl> but if you got blobs, it may be time to upgrade :)
<[7]> which side of the blob? kernel or userspace?
<Turl> kernel is open source
<Turl> only blob is in userspace
<[7]> and my SDK came with r3p2 as well
<[7]> I just need the kernel part for that
* WarheadsSE needs a cubietruck at some point
<[7]> and whatever is in the AW 3.3 tree is a mess
<WarheadsSE> ^ I need to get our sun7i kernel off that.
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
<[7]> hm...
<[7]> W/libEGL ( 489): eglInitialize(0x1) failed (EGL_BAD_ALLOC)
<[7]> E/[Gralloc-ERROR]( 489): int alloc_device_open(const hw_module_t*, char const*, hw_device_t**):441 UMP open failed with 1
<[7]> E/SurfaceFlinger( 489): ERROR: failed to open framebuffer, aborting
<[7]> E/SurfaceFlinger( 489): framebuffer_open failed (Operation not permitted)
<[7]> that's ssvb's kernel patch with the allwinner r3p2 blob from the linux 3.3-based allwinner android SDK
<WarheadsSE> mm
adb has joined #linux-sunxi
<[7]> there we go: http://pastie.org/8523289
<[7]> any hints?
<rm> very cheap A20 tablet on the cybermonday sale
<ssvb> [7], could you please post the android & mali summary information to the mailing list?
<ssvb> [7], does mali r3p2 work with 3.3 kernel (or any other kernel) in android at the moment?
<[7]> it does seem to work with allwinner's 3.3 kernel, yes
<ssvb> [7], do you have android mali r3p2 userspace blobs?
<[7]> I think so, yes
<[7]> DX910-SW-99002-r3p2-01rel0 to be more specific
<mripard_> oliv3r: I have no idea.
<ssvb> [7], hmm, are they really the same? we have r3p2-01rel2 blobs for linux
<ssvb> [7], can you check the mali version id in the android mali kernel sources?
<[7]> hm, the ones that I use are from allwinner's android SDK v1.2
<[7]> in which file do I find that?
<[7]> ssvb: #define _MALI_API_VERSION 19 if that's what you need
<ssvb> yes, _MALI_API_VERSION define, and for linux we have it set to 20
<ssvb> which means that they are very likely incompatible
<[7]> hm, indeed
<[7]> so I should probably diff that kernel source
<ssvb> [7], we are really better to have matching blobs for both linux and android
<ssvb> or they just can't use the same kernel
<[7]> sure, but I care primarily about getting android to work on a sane kernel right now :)
rellla3 has joined #linux-sunxi
<ssvb> [7], you can have a look at my 20130913-mali-r3p2-01rel2 branch, the original mali kernel driver sources and sunxi adaptation changes are committed as separate patches
<[7]> I'm doing that right now
<[7]> the changes between v19 and v20 are fairly small so far
<[7]> mostly obvious bug fixes
rz2k has joined #linux-sunxi
<ssvb> you also probably need to try enabling dma_buf (based on the messages from your pastebin log)
rellla3 has quit [Client Quit]
<ssvb> [7], also please write something about your progress to the linux-sunxi mailing list
<[7]> ssvb: regarding that DMA problem, that might be EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL related, need to check that later
<[7]> I'll first try to sort out the differences between v19 and v20
<ssvb> ok, thanks
<ssvb> posting something to the mailing list would be very useful because right now the participation from android people is almost non-existent
<ssvb> and it's difficult to get an idea whether anyone is interested in this stuff or not :)
rellla3 has joined #linux-sunxi
pitillo has quit [Ping timeout: 260 seconds]
flatr0ze_ has joined #linux-sunxi
<eagles0513875> any buildroot and cubieboard experts in here
<libv> eagles0513875: instead of asking for people, why don't you just ask your actual question?
<eagles0513875> basically i found an issue when trying to run the script to generate the images for the cubieboard
<eagles0513875> cubieboard2
rellla3 has quit [Remote host closed the connection]
geecko has joined #linux-sunxi
Quarx has quit []
<mripard_> eagles0513875: you still didn't ask anything.
<eagles0513875> mripard_: hold on
<mripard_> you have an issue. Ok. Which is ? how do you reproduce it ? What is your buildroot version ? with what configuration ?
<mripard_> give us something, or we won't be able to help you.
<eagles0513875> ok hold on
<Nyuutwo> eagles0513875: some log of executing script?
<eagles0513875> basically i want to create the images using the cubieboard script that is available yet it wants me to specify the output directory but nothing has been generated yet
<eagles0513875> what is the command to generate the images
<eagles0513875> this is the command im running yet its obviously not finding the images obviously because i have not generated them ./mkcubiecard.sh output /dev/sdb1
<mripard_> eagles0513875: have you read the readme.txt that is just beside this script ?
<eagles0513875> yes but re reading it i forgot the sudo
<eagles0513875> mripard_: now when i run that command im getting ./mkcubiecard.sh: 31: [: -ne: unexpected operator
n01 has quit [Quit: leaving]
<mripard_> no, you haven't read it. or not properly
<mripard_> otherwise you'd know that you have to use output/images, and that you should use /dev/sdb in your case
<eagles0513875> mripard_: im still getting that error ./mkcubiecard.sh: 31: [: -ne: unexpected operator
<eagles0513875> i dunno if that is a bug in the script or me
* eagles0513875 goes to reread the readme
<mripard_> eagles0513875: what shell are you using?
<eagles0513875> bash
<mripard_> it's installed as /bin/sh ?
<eagles0513875> im not sure
<eagles0513875> i added bash though before the script and it got rid of the error
<eagles0513875> thing is that its complaining files are missing
<eagles0513875> sudo bash mkcubiecard.sh output/images /dev/sdb File(s) missing.
<mripard_> have you run make ?
<mripard_> at some point
<eagles0513875> thanks thats what i forgot
<mripard_> it was in the readme.txt.
y0g1 has quit [Ping timeout: 272 seconds]
<eagles0513875> my fault i forgot to pipe less into cat
<eagles0513875> doh
aesok has joined #linux-sunxi
diego71 has quit [Ping timeout: 245 seconds]
diego71 has joined #linux-sunxi
y0g1 has joined #linux-sunxi
Md has quit [Quit: Mea navicula pendens anguillarum plena est]
<oliv3r> hansg working on mmc! awesome
<oliv3r> 3.15 will eb interesting
<hno> oh? There is work on a clean MMC implementation?
<oliv3r> for linux, yeah mainline work
<oliv3r> hansg cleaned up the existing tree
<hno> Is there also any attempt at documenting the controller?
paulk-collins has joined #linux-sunxi
_massi_ has quit [Remote host closed the connection]
* [7] is slowly making progress
<[7]> I managed to compile the kernel part for v19 mali
<[7]> surfaceflinger still crashes though, for whatever reason:
<[7]> E/SurfaceFlinger( 1802): EGLContext creation failed
<[7]> F/SurfaceFlinger( 1802): couldn't create EGLContext
<[7]> F/libc ( 1802): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 1803 (SurfaceFlinger)
<[7]> I/SurfaceFlinger( 1802): SurfaceFlinger run00.
<[7]> ideas?
xeros has quit [Read error: Connection reset by peer]
y0g1 has quit [Read error: Connection reset by peer]
y0g1_ has joined #linux-sunxi
xeros has joined #linux-sunxi
<zumbi> mnemoc: hey - ayh?
FR^2 has quit [Quit: Connection reset by peer]
<zumbi> mnemoc: do you know any cubietruck spanish re-seller?
<mnemoc> en el metro...
<mnemoc> nope
<zumbi> gracias / thanks
<mnemoc> I received mine from .de
<jelly-home> nice canary value there
y0g1_ has quit [Remote host closed the connection]
xeros__ has joined #linux-sunxi
xeros has quit [Read error: Connection reset by peer]
<hramrach> ehlo
xeros__ is now known as xeros
adb has quit [Ping timeout: 246 seconds]
y0g1 has joined #linux-sunxi
<hramrach> [7]: the idea is that you should debug EGL context creation. Unfortunately you are running Android which is not meant to be self-hosted so has no tools on it and is totally undocumented. At least looking around for info on doing something with Andriod other than writing apps turned up pretty much nothing
<hramrach> all the docs assume that your device vendor gives you a magic foo that you burn on your device and don't care about anything but flooding AppStore with 100th half-broken clone of some app
wingrime has quit [Ping timeout: 248 seconds]
<hramrach> because every other app is free to use but source-less so the total sum of bugs in them is staggering and finding a working app is rather challenging
<[7]> hm, it works with the same userspace on a different kernel... so there must be something wrong in this kernel
<hramrach> do you have mali as module or built-in?
<hramrach> android does not do module autoloading
<[7]> init.rc has loaded the module just fine
<[7]> building it in doesn't work IIUC
<hramrach> and does the libmali match the mali revision the revision this kernel supports?
<[7]> it should
<[7]> the userspace is v19, from allwinner's 3.3 sdk
torindel has quit [Ping timeout: 265 seconds]
y0g1 has quit [Read error: Connection reset by peer]
y0g1 has joined #linux-sunxi
<hramrach> the mali revisions are like r30p2 or something
<hramrach> v19 is something else
<[7]> the kernel is linux-sunxi 3.4, patched with v20 patches from ssvb, then merged with allwinner's v19 kernel
<[7]> v19 is the internal version number
<hramrach> hmm
n01 has joined #linux-sunxi
<[7]> let me look that up
<[7]> v19 is DX910-SW-99002-r3p2-01rel0 from allwinner's sdk, v20 is mali_r3p2-01rel2 from ssvb
<hramrach> you can like try to boot Linux on top of your Android kernels and see if there is any difference in EGL creation
<[7]> my suspicion is that I might screwed something up while merging v19 from 3.3 into v20 from v3.4
<hramrach> actually, Ubuntu has lxc setup for running android in chroot packaged. might be quite useful
<ssvb> [7], maybe it's a good idea to have a look at the mali kernel module sources from the 3.3 android kernel?
<[7]> ssvb: I mostly replaced yours with those
<[7]> but they're building them a bit differently
<[7]> and the platform integration stuff works a bit different
<[7]> so I basically tried to keep your build- and linux-sunxi-related changes, while merging most of their driver code base
<Turl> zumbi: there is one listed on the cubie site I think
adb has joined #linux-sunxi
<zumbi> Turl: which cubie site?
<Turl> 3 resellers in spain in fact
<zumbi> Turl: thanks
<zumbi> now to check it they got cubie3
<hramrach> zumbi: DX has ;-)
<zumbi> hramrach: what is DX?
<zumbi> Turl: on spanish sites, 2 consultants and 1 shop, which does not seem to have cubie3
<zumbi> uhm.. nvm, one of the consultants has it
<zumbi> but no stock, damn it
<hramrach> DX is dx.com
<hramrach> they have 'worldwide free shipping' meaning everything that needs actual packaging to ship is overpriced :p
torindel has joined #linux-sunxi
<zumbi> I was looking at http://embeddedcomputer.nl
torindel has quit [Read error: Connection reset by peer]
<zumbi> hramrach: actually, it is cheaper at dx.com
<Turl> chinese shipping can take a while though, esp. on holiday season
y0g1 has quit [Read error: Connection reset by peer]
torindel has joined #linux-sunxi
<zumbi> is that china site?
y0g1 has joined #linux-sunxi
<zumbi> oh, yeah, it is
<Turl> dealextreme? yes
y0g1 has quit [Read error: Connection reset by peer]
y0g1 has joined #linux-sunxi
y0g1 has quit [Remote host closed the connection]
y0g1 has joined #linux-sunxi
Nikolas- has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 258 seconds]
Nikolas has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
<[7]> hm, "Symbol: SUNXI_MALI_RESERVED_MEM [=n]"
<[7]> might that be the problem?
<[7]> or does mali grab all the memory it needs at runtime through UMP?
<hno> [7], there is two memory reservation models for MALI. Static allocation at compile time, or dynamic runtime.
<[7]> how do I select which one to use?
<hno> Ther is both kernel .config parameters and kernel command line arguments. Don't know the exact details as I don't use MALI at all, but was involved long ago trying to get this in some reasonable shape..
<[7]> hm, what else could make EGLContext creation just fail without further messages...
\\Mr_C\\ has quit [Quit: .]
<oliv3r> hno: how's work? slowing down at all?
<hno> oliv3r, at least changing...
<hno> but family is ramping up at same time...
<hno> but nothing as crazy as september-october in sight.
tomboy64 has quit [Remote host closed the connection]
<oliv3r> yeah december time is family time
tomboy64 has joined #linux-sunxi
<oliv3r> hno: will you go to fosdem?
geecko has quit [Ping timeout: 272 seconds]
jinzo has quit [Ping timeout: 265 seconds]
<[7]> hm... [pid 9953] ioctl(16, 0xc0048207, 0x4053ec80) = -1 ENOTTY (handle 16 is /dev/mali)
* [7] wonders where the handler code for that is hiding
jinzo has joined #linux-sunxi
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
geecko has joined #linux-sunxi
n01 has quit [*.net *.split]
notmart has quit [Quit: notmart terminated!]
n01 has joined #linux-sunxi
zeRez has joined #linux-sunxi
n01 has quit [Read error: Operation timed out]
rz2k has quit []
<hno> oliv3r, I hope to, but can't plan for it yet.
<hno> oliv3r: and we are expectig out 7'th kid around newyear.
zeRez has quit [Quit: zeRez]
<hno> oliv3r, christmas is only temporary.
AreaScout has quit []
Black_Horseman has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
zeRez has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
<[7]> to all of those people whom I have annoyed with my mali chaos today... I think I've figured it out :)
tzafrir has quit [Ping timeout: 246 seconds]
<[7]> hm, snd_sw_ace_suspend calls clk_get_rate on a bad clockgate name
<eagles0513875> ok thats not right
<eagles0513875> how the heck do i have an image which is 0.00k
<[7]> weird indeed :P
<eagles0513875> [7]: what board tdo you have
<[7]> a20 olinuxino
<eagles0513875> im on an a20 cubieboard2
<eagles0513875> well the images have size to them i guess i need to just copy them to the microsd card
<eagles0513875> sadly cant do anythign until tomorrow anyway
<eagles0513875> as i dont have the board with me
zeRez has quit [Quit: zeRez]
<ssvb> [7]: what was it? :) do you have some patches to share?
<[7]> it was just too simple
<[7]> mali can't do much if CONFIG_SYNC=n
<[7]> that just ifdef's out most of the important ioctl handlers
<[7]> so we should maybe give it a dependency on that, even though it technically works without it
<[7]> it's just not very useful :P
<[7]> I'm using the v20 driver now btw, with v19 userspace
<[7]> as far as I can tell it can be made compatible by commenting like 5 lines
<ssvb> [7]: android used to be a blocker for r3p2 mali upgrade, I guess now we have a chance to integrate it into linux-sunxi in a civilized way :)
<[7]> it's basically two struct fields that need to be removed, along with all dependencies
<[7]> I haven't really stress tested it yet though, as my board keeps playing annoying suspend-resume loop games...
<ssvb> please post the android mali r3p2 step by step instructions to the linux-sunxi mailing list, this is going to be really appreciated
<[7]> I'll do so in a few days, when I have sorted out the remaining problems to test if this actually works somewhat stable
<[7]> I have quite a bit of a mess to clean up here...
<ssvb> thanks a lot in advance
<[7]> wouldn't have been possible without all those hints from various people in here :)
<ssvb> you are welcome :)
n01 has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
ganbold_ has quit [Remote host closed the connection]
* [7] fixes some null pointers in sun4i_dev_ace
<tomboy64> is i wanted to ask about the state of drivers for the cubietruck
<tomboy64> mostly wlan (bcmdhd)
<[7]> that tp_do_tasklet null pointer oops also still occurs from time to time
<tomboy64> is that usable? or at least being worked on?
<[7]> if someone has a clue what kind of debug output I might need to add, I'd be happy to help nailing that one down
<[7]> next up: what's wrong with that touchscreen...
y0g1 has quit [Remote host closed the connection]
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
adb has quit [Ping timeout: 260 seconds]
n01 has quit [Ping timeout: 260 seconds]
tzafrir has joined #linux-sunxi
focus2 has joined #linux-sunxi
geecko has quit [Read error: No route to host]
focus2 has quit [Client Quit]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
<[7]> why on earth does that touchscreen behave like a laptop touchpad...
naobsd has joined #linux-sunxi
geecko has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi