<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>
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 :)
<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]
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
<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
<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
<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
<Turl>
mripard_: I have BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y
<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>
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...
<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
<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)
<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
<[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...
<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
<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
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
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]