[03:51] <tansell> Hi guys, are there instructions for porting ubuntu arm to another arm based system? I know my device is supported by recent kernels and works with debian but I'd strongly prefer to use ubuntu
[05:39] <LetoThe2nd> tansell: well if your system is armv7+x, basically just create a fitting kernel+initrd and use the ubuntu userland from there on as a first start
[06:42] <Heradon> good morning
[06:49] <Heradon> i need a little help, to flash my gooseberry ;) i need to use ubuntu ^^
[06:54] <lilstevie> gooseberry?
[06:55] <Heradon> yes it is a Allwinner A10 board
[06:55] <lilstevie> yeah, just looked it up
[06:56] <Heradon> but the newer version of the board does not boot from MMC
[06:56] <Heradon> i think i need a newer uboot
[07:01] <Heradon> but i dont know :(
[07:07] <LetoThe2nd> if you "don't" know, better do not touch the uboot as you are prone to brick the thing.
[07:07] <Heradon> good but i need a ubuntu on this board ^^
[07:08] <LetoThe2nd> well i need 100k€, but the world does not care either.
[07:08] <LetoThe2nd> if you a) do not know what you are doing b) risk bricking the board c) have no means to unbrick it - do not do it.
[07:09] <Heradon> good, i can do this board into trash
[07:09] <Heradon> android on my TV is ....
[07:10] <LetoThe2nd> sorry, but do not complain if you bought things that are not made for endusers, if you are an enduser.
[07:11] <LetoThe2nd> plus, their documentation is totally poor. or should i say "cheap"?
[07:11] <Heradon> the doku is crap
[07:11] <Heradon> I bought the board as ubuntu was still running from the MMC, but the delivery has been delayed and it hies then suddenly it will not boot from the MMC and now I'm looking for someone who can help me
[07:12] <LetoThe2nd> well if u-.boot is actually the reason, then the standard procedure is: get source, find bug, patch it, compile, flash
[07:13] <Heradon> need for flash anyone other hardware of the USB?
[07:13] <LetoThe2nd> but if even the manufacturer is to lazy/dumb to do that properly, and you are a mere enduser, then - well, you're whacked.
[07:13] <LetoThe2nd> usually u-boot can re-flash itself, unless it is bricked. so you need uboot access.
[07:14] <Heradon> the uboot access i become only with UART right?
[07:14] <LetoThe2nd> and you need a memory map, or the knowledge to read/interpret what uboot is telling you.
[07:15] <LetoThe2nd> well there uarts over usb too.
[07:15] <LetoThe2nd> these are things that you have to know if you want to tinker with something
[07:15] <Heradon> good i have no uart.. perfect
[07:15] <Heradon> i sell my gooseberry and buy a odroid-x
[07:16] <LetoThe2nd> do not complain to us if you have bought literally "cheap" hardware that you do not understand ;)
[07:17] <LetoThe2nd> they even say "only android ATM", which reads as "anything else only if you really know your stuff"
[07:18] <Heradon> i have 3 raspis, no problem i compile my own system. But the goosebery is ARG
[07:18] <LetoThe2nd> i really doubt that you compiled ubuntu for raspi ;)
[07:18] <Heradon> no i compile archlinux for raspi :>
[07:19] <LetoThe2nd> ah yes. *impressed*
[07:20] <Heradon> on my first computer i have gentoo, on my second pc ubuntu ^^ laptop lubuntu and netbook archlinux :O
[07:21] <LetoThe2nd> sorry to burst your bubble, but running neither gentoo nor archlinux makes you automatically someone who understands compiling or the inner workings. it just makes you someone who either is successfull in reading or experimenting.
[07:22] <LetoThe2nd> so coming back to the initial topic: running ubuntu on thath thing is probably doable. but judging from the pretty much non-existent documentation/source from the manufacturer, it boils down to considerable barin/time effort, and not some 1-2-3 type this, click here guide.
[07:23] <Heradon> i know, i work on the board since 2 weeks
[07:24] <LetoThe2nd> hence, if you're willing to go that route - provide information as precise as possible, and people will probably try to help and give pointers. but the most of the work will certainly be up to you.
[07:24] <Heradon> i know
[07:24] <LetoThe2nd> (if you're "working on" something since 2 weeks and do not even know how to access u-boot,.... well thats no good sign.)
[07:24] <Heradon> stop stop
[07:25] <Heradon> you are german? ^^
[07:25] <LetoThe2nd> i am, but i will neither do query support nor change to german here as the official channel language is english.
[07:26] <Heradon> ok, no problem but my english is very bad ^^ this is my first touch with uboot. i read the time dokumentations and boards on internet
[07:26] <LetoThe2nd> so back again: topic 1) for you is: get u-boot access. if you have that, come back and present the informations that one can get from that.
[07:28] <Heradon> can you give me a link to buy a uart interface?
[07:28] <LetoThe2nd> no, because i have absolutely no clue what you need. you have to find out where the manufacture has wired the A10s uart to.
[07:29] <Heradon> i sell the board
[07:29] <LetoThe2nd> if it comes out on a header, or a sub-d, or maybe it even is an additional usb endpoint.
[07:29] <LetoThe2nd> like i said: you have to invest your own brain power.
[07:30] <Heradon> i have an uboot log
[07:30] <LetoThe2nd> coming from where? if it magically appears on some sd card, that provides no information.
[07:31] <Heradon> https://gist.github.com/3364042 here an bootup
[07:31] <LetoThe2nd> like i said: how did you get that log?
[07:32] <Heradon> google ^^
[07:32] <LetoThe2nd> meh.
[07:32] <Heradon> i have all informations from google
[07:32] <LetoThe2nd> sorry, but this is becoming totally ridiculous.
[07:32] <LetoThe2nd> sell the board.
[07:33] <Heradon> ich hau mit dem hammer auf den scheissdreck -.-
[07:33] <lilstevie> most A10 devices are hard to brick fwiw cause of fex/livesuite
[07:33] <LetoThe2nd> lilstevie: doesn't make them easier to flash if you do not even know how to access the console ;)
[07:33] <lilstevie> heh
[07:34] <lilstevie> LetoThe2nd, fex/livesuite is over usb
[07:34] <Heradon> i have flashed 4 times alternatives androids to the board
[07:34] <lilstevie> bootrom recovery like nvflash
[07:34] <lilstevie> :p
[07:34] <LetoThe2nd> i already stated several times that finding out how to access u-boot must be topic #1. i really am getting tired a bit.
[07:34] <lilstevie> but yes
[07:35] <lilstevie> if you cannot interact with u-boot there is no point trying to debug it
[07:35] <lilstevie> "[
[07:35] <lilstevie> :p
[07:35] <LetoThe2nd> and repeatedly suggesting us that you have knowledge because you "flashed something" or "compiled something", but then asking very basic questions is also... lets say not very reassuring that we are spending effort for good here.

[07:44] <Heradon> so das board bootet nie wieder
[07:45] <RoyK> LetoThe2nd++
[08:15] <tirumal> Hi, new to this forum. Is screen rotation possible using SGX pvr driver for ubuntu 12.04 on pandaboard(Rev A4)?
[08:18] <tirumal> I have tried with ubuntu 11.04 by changing the bootargs parameters in boot.scr and it didn't work
[08:34] <sveinse> As previously discussed, plymouth is unable to show splash and show console on serial terminal simultaneously. This is something I must fix. I can do it in one of two ways: 1) I can set plymouth to textmode and implement my own framebuffer displayer 2) I can alter plymouth to show framebuffer splash _and_ show text on serial console. Which do you think is less work and most trivial?
[08:46] <tirumal> I want to rotate my screen by 90 degree. Is it possible using omapdrm driver?
[09:03] <ogra_> tirumal, did you try xrandr ?
[09:05] <tirumal> ogra_: No i didn't try. How can I do it with xrandr?
[09:06] <ogra_> sveinse, hard to tell, and definitely nothing upstream will take either way, they consider a system where the console= arg appears a system that doesnt want a splash, i guess there is some code to catch that arg that parses the dmclie, did you try to just comment that ?
[09:06] <ogra_> s/dmclie/cmdline/
[09:08] <sveinse> ogra_, I can select between textmode and a gfx theme with the second console= option. However the gfx theme supresses console output, which is the bad thing here
[09:09] <ogra_> well, find the code caring for console= and comment it ;)
[09:09] <sveinse> So perhaps it's possible to write a gfx theme which accepts the console texts and diverts it to the serial console
[09:10] <ogra_> that should give you  2)
[09:11] <sveinse> I notice I have to specify console= twice for it to set plymouth. why is that? the first is for the kernel, the second for ply?
[09:12] <ogra_> usually the first is for kernel and the second for userspace
[09:12] <ogra_> it should switch to the scond once some kind of rootfs is available
[09:12] <ogra_> (i.e. an initrd)
[09:14] <sveinse> if using one console=ttyO2, what does ply consider console to be (since kernel now uses console ttyO2)? /dev/fb0? /dev/tty1 perhaps
[09:14] <sveinse> (i.e. it's userspace which sets up /dev/console, not kernel, right)
[09:17] <ogra_> ply simply shuts down in that case
[09:19] <ogra_> well, setting up /dev/console was theoretically done in userspace in the past. yeah, the kernel just attaches the default console to it once there is a /dev ... though nowadays we use devtmpfs everywhere which the kernel creaates ... i guess that area got blurry due to that
[09:19] <sveinse> No it does not. We're run on this for a while. We have one console=ttyO2 in commandline, the kernel boots and output kernel output on serial port, and then it drops silent when displaying png on fb0.
[09:19] <ogra_> well, i should have said it shuts down all display actions
[09:19] <sveinse> The "only" problem is that it drops slient between kernel and getty
[09:20] <ogra_> it still provides that dbus like interface for apps (encryption etc) but doesnt provide any frontend anymore
[09:21] <sveinse> yes. to be honest, since our device is very specialized, we'd hoped on purging plymouth alltogether. But its very interwowen with everything
[09:22] <sveinse> ..in an attempt to save boottime
[09:23] <ogra_> well, you need libplymouth at least
[09:25] <sveinse> yes, I've accepted that fact that plymouth is unremovable, so thus the effort to get the console output to the serialport
[09:29] <ogra_> did you consider using something like feh from the initrd to just throw a static picture on the framebuffer ?
[09:29] <ogra_> (or any other minimal image viewer that can talk to fb0)
[09:30] <ogra_> err, fbi, not feh
[09:31] <ogra_> (no idea how much that bloats your initrd in size though)
[09:35] <ogra_> ogra@zatab:~$ ls -l /dev/|grep mmc
[09:35] <ogra_> ogra@zatab:~$
[09:36] <ogra_> hmm, that might be the reason why i cant boot that thing from mmc
[10:07] <sveinse> ogra_: Yes. But fbi is large and bloated, so I've stripped down fbi to the bare metal to do exactly that. However, I can't rid myself of dependency on libm (via libpng), so it's larger that I'd like.
[10:08] <sveinse> But I notice now that plymouth in initramfs is also depending on libm, so its already there I guess
[10:09] <ogra_> yep
[10:09] <ogra_> well, it might go away if you remove the graphical themes
[10:09] <ogra_> not sure plymouoth itself will pull it into initrd for a text theme
[10:10] <sveinse> i'll figure it out. In all cases I need a hook for my mini-fbi anyways, so I will pull in libm from there
[12:00] <tirumal> ogra_: thanx for the hint, it works well on desktop pc but not my target platform with omap4
[12:00] <ogra_> well, it should, at least in quantal where we install the pvr driver by default
[12:00] <tirumal> when i try with command: xrandr -o left it fails with X Error : Bad Match
[12:01] <ogra_> xrandr itself gives oyu proper ouput (if you run it without any options) ?
[12:03] <tirumal> ogra_ : it says: HDMI-1 is connected with 1280x1024 with 60 freq
[12:03] <ogra_> k, so xrandr support is generally working
[12:03] <tirumal> yes
[12:04] <ogra_> any more info in Xorg.0.lo ?
[12:04] <ogra_> *log
[12:04] <tirumal> one more interesting  thing: I have tried the same command on variscite omap4 board, where it works
[12:06] <ndec> tirumal: with the same kernel?
[12:07] <ndec> rotation support was added lately, but it could be flaky at times...
[12:08] <tirumal> where I have patched Mr. Clarks drm/omap: add rotation properties
[12:09] <tirumal> ndec: no with different kernel. It works with 3.4.0-1486-omap4 kernel
[12:10] <ndec> yeah, we did some bug fixes/rework for rotation, so that might explain.
[12:10] <ndec> i would generally recommend to stick to 3.4 kernel for OMAP4, this is what we (TI) support.
[12:14] <tirumal> ndec: to be more clear on this rotation issue: I have understood that with SGX pvr driver, one should be able to rotate the screen by 0, 90, 180, 270 + graphical acceleration
[12:14] <tirumal> ndec: Is that pvr driver already integrated in 3.4 TI kernel?
[12:15] <tirumal> ndec: by providing kernel boot with omapfb.rotation=1 for 90 degree rotation, what i need
[12:16] <ogra_> stgraber, highvoltage, so we have a massive issue with the mmc controller in our kernel for the zatab ... and we seem to be missing this touchscreen driver https://groups.google.com/forum/#!topic/android-x86/vEKSSKdUfi8
[12:17] <ndec> tirumal: yes, we have rotation support with GFX with 3.4 kernel. I don't know if it's working or not with 12.10 kernel...
[12:17] <ndec> omapfb has been deprecated.
[12:17] <ogra_> the -omap xserver should support it even withjout pvr installed afaik
[12:19] <ndec> ogra_: yes, this is correct.
[12:19] <ndec> you don't need PVR for xrandr (resize nor rotate)
[12:19] <ogra_> but that indeed needs 12.10
[12:20] <ogra_> (i dont think 12.04 even had that recent -omap xserver package)
[12:23] <ndec> right, it didn't
[12:24] <ndec> ogra_: what's the pkg src name for -omap?
[12:24] <ndec> ok, found...https://launchpad.net/ubuntu/+source/xf86-video-omap
[12:24] <ogra_> xf86-video-omap
[12:25] <ogra_> yeah
[12:25] <ogra_> before quantal that was just xfbdev with some sauce added i think
[12:26] <ndec> ogra_: we seem to have an extra patch in our -omap (    - xrandr-rotation.patch). not sure if you have that one.
[12:27] <ogra_> i think we have the latest upstream and would trust rob to keep that updated
[12:28] <ndec> i don't think rotation is upstream
[12:40] <tirumal> ndec, ogra_ thanx for the impt info regarding pvr & rotation features
[12:40] <ndec> np
[12:44] <tirumal> we are using a Phytec omap4 module, which has Pengutronix distribution with kernel 3.3 and that explains the behaviour
[12:59] <highvoltage> ogra_: ah. that's a bummer. I'll try a 3.4 kernel tonight if you haven't beaten me to it yet
[13:02] <tirumal> I am intrested to know: where would be the pvr driver located so that I can integrate it on my target
[13:14] <deffrag> Hi! I have a code prepared and compiled on x86_64 architecture which I moved to and compiled on ARM(Beagleboard XM). And, it worked without errors exactly as it would on x86_64. Same commands were executed to compile and run. I'd like to know what made it happend, how does it work?
[13:15] <stgraber> ogra_: but didn't you manage to boot from mmc once?
[13:22] <hrw> deffrag: pure magic
[13:23] <ndec> ;-)
[13:24] <deffrag> hrw: Bah.
[13:24] <deffrag> Isn't it related to cross-compilation or such? gcc for arm configured for the platform ...
[13:24] <hrw> deffrag: you compiled natively
[13:24] <hrw> deffrag: cross is when you are on HOST (arch1) compiling for TARGET (arch2)
[13:26] <hrw> there is also canadian cross when you are on BUILD (arch1) compiling compiler for HOST (arch2) to build for TARGET (arch3) - but thats crazy
[13:27]  * hrw -> lunch
[13:28] <deffrag> Ok, natively compiled. Compiled on the architecture  running. So, what is making that possible? What is the difference made in gcc for arm
[13:29] <deffrag> Otherwise, could anyone link me to some resource for the same?
[13:38] <ogra_> stgraber, yeah, but not with this kernel, i tried random uImages from different prebuilt images
[13:38] <ogra_> hmm, seems there is also a sun4i-ts driver, i wonder if that one would work
[13:39] <ogra_> seems the other one from above needs a binary blob
[13:39] <suihkulokki> allwinner hacking going on?
[13:40] <ogra_> yep
[13:41] <hrw> deffrag: it is same gcc
[13:41] <hrw> deffrag: gcc supports wide range of archs
[14:01] <ogra_> highvoltage, there is a 3.4 tree ?
[14:01] <highvoltage> ogra_: ah no, there isn't :-/
[14:02] <ogra_> sad, you just had me hoping :)
[14:02] <ogra_> aha
[14:02] <ogra_> https://github.com/zareason/linux-allwinner/commit/c5ce10353d48a704540cd8fa0c5d2e90e380aaf8
[14:02] <ogra_> seems the zareason tree has the touchscreen driver
[14:05] <highvoltage> ogra_: how's the transformer doing these days? is there a tablet ubuntu is known to run well on?
[14:05] <ogra_> no idea, my transformer only runs android :)
[14:05] <deffrag> hrw: Ok, thanks.
[14:05] <deffrag> Secondly, how can I use/enable DSP? I followed - http://elinux.org/BeagleBoardUbuntu#gst-dsp - but it says module bridgedriver not found. I searched for its .ko file, its not present.
[14:06] <ogra_> highvoltage, asl lilstevie
[14:06] <ogra_> *ask even
[14:06] <highvoltage> good, because I wasn't going to ask him a/s/l.
[14:07] <lilstevie> thats good cause I wasn't going to respond :p
[14:07] <ogra_> i have the slight feeling that https://github.com/zareason/linux-allwinner might be the better suited kernel tree
[14:07] <highvoltage> lilstevie: do you run ubuntu on your transformer?
[14:08] <lilstevie> highvoltage, absolutely
[14:08] <lilstevie> transformer or transformer prime
[14:08] <highvoltage> I guess transformer prime, ideally
[14:08] <highvoltage> does it run ok?
[14:10] <lilstevie> it runs fine, just not really prime time ready
[14:10] <lilstevie> still things that don't work as expected
[14:10] <ogra_> highvoltage, stgraber ... hmmm ... i guess someone should package http://linux-sunxi.org/Mali400#Mali-400_X11_DRI2_drivers
[14:12] <ogra_> http://limadriver.org/ doesnt seem to be ready yet
[14:13] <stgraber> yeah, hopefully we can get a kernel and the mali driver in 13.04, assuming there's no redistribution problems with the blob
[14:14] <ogra_> well, linaro seems to provide allwinner images with it included
[14:14] <ogra_> or hwpacks
[14:15] <ogra_> so it must be redistributable i guess
[14:16] <ogra_> if we want images in 13.04 we should start building stuff in ppas (in fact i'd like 12.10 images even if the are handrolled, but close to what 13.04 will have)
[14:16] <ogra_> wow, my fingers always want to type 13.03 :)
[14:17] <highvoltage> hopefully it will want to follow the same pattern for 14.04 :)
[14:18] <highvoltage> (maybe by then you're fingers will have been trained to type 14.05 by then)
[14:18] <ogra_> who cares about 14.04 ...
[14:18] <ogra_> we'll all be old an grey by then
[14:18] <ogra_> :)
[14:18] <highvoltage> I'll have to copy and paste that to quote in a few months ;)
[14:18] <ogra_> heh
[14:24] <stgraber> yeah, getting what's needed in a PPA would be good, for Edubuntu we'll probably just grab our armhf (omap4) squashfs, remove the kernel, install the PPA, pull the new kernel and install the X driver, then do a bit of repacking to work on the mmc. Writing a script doing that should be trivial once we have the bits in place.
[14:25] <ogra_> well, i would actually propose a proper preinstalled image
[14:26] <ogra_> for later we can have live or so to do an actual install to flash if people want it
[14:31] <tirumal> ndec,ogra_: Regarding the pvr driver for omap4. where would be pvr driver located? I am asking  this because later I have to  integrate it in my distribution and use graphics acceleration
[14:32] <ogra_> tirumal, well, pvr is usually only working with a certain kernel version ...
[14:32] <ogra_> so you need both
[14:32] <ogra_> i would recommend the versions from quantal here
[14:35] <tirumal> ogra_:Agree but at the end I want to use them on my target omap4 platform, which uses pengutronix dist
[14:36] <ogra_> https://launchpad.net/ubuntu/+source/pvr-omap4/ has the driver packages
[14:37] <ogra_> the omap4 kernel is on the kernel.ubuntu.com git ... look for ppisati's name there :)
[14:45] <tirumal> ogra_: ok got it
[14:51] <ogra_> rsalveti, hackin on a zatab here, do you know if the binary blobs for mali are redistributable (and coudl we perhaps get he xserver that linaro seems to have in a ppa into the archive) ?
[14:54] <rsalveti> ogra_: I think so, we just need to test first if the xorg driver we have works with whatever binary you're trying out
[14:54] <ogra_> great
[14:55] <ogra_> (just dipping my toe in the water here to find out about all the bits and pieces)
[16:20] <deffrag> Hi! Why in the image used - http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-server-armhf+omap.img.gz - for Beagleboard xm, it is not possible to have DSP working? Why 12.04 has no dsp bridge?
[16:31] <deffrag> Hi infinity
[17:10] <GrueMaster> deffrag: Are you referring to audio?
[17:12] <GrueMaster> See bug 925094 for some possible solutions.
[17:12] <ubot2> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
[17:16] <deffrag> GrueMaster: Hi! No, I've sound working. I would like to attempt something related to image processing on this platform for which DSP are good. I'm curious how would one use them. For http://elinux.org/BeagleBoardUbuntu#gst-dsp it assumes using rcn image. When I tried those instructions, it gave bridgedriver missing. I'm not sure what is the proper method of engaging DSP
[17:18] <GrueMaster> Ah.  Sorry, can't help there.