[06:36] <BV1AL> I connected USB HUB to the OTG and it work for my keyb/mouse when I boot TI Blaze with Android ICS.
[06:36] <BV1AL> But if I boot ubuntu-12.04-preinstalled-desktop-armhf-omap4 on TI Blaze, and with the same connection(USB HUB keyb/mouse)
[06:37] <BV1AL> the keyb/mouse has no any response even though I can see the Ubuntu desktop on HDMI monitor
[06:37] <BV1AL> what can I do to solve this problem ? so I can start to configure Ubuntu.
[06:39] <scientes> BV1AL, AFAIK OTG ports are reverse ports
[06:39] <scientes> so they don't work for what you want
[06:42] <BV1AL> so this means I cannot run Ubuntu ? but only ICS ?
[06:42] <scientes> nono
[06:42] <BV1AL> because the keyboard on Blaze has no any response when I boot to Ubuntu
[06:43] <scientes> BV1AL, can you login via ssh?
[06:43] <BV1AL> so I need a external keyb
[06:43] <BV1AL> it has no network connection even I plug the ethernet to Blaze
[06:43] <scientes> then you need to log in via the serial console
[06:44] <BV1AL> serial port has no any response either
[06:45] <BV1AL> the monitor waiting me to select language for the system, but I can do nothing
[06:46] <scientes> did you unplug and replug in the keyboard?
[06:47] <BV1AL> yes I did
[06:47] <scientes> did you try with no hub?
[06:48] <scientes> anyways serial port is your best bet
[06:49] <BV1AL> in the beginning, the serial has messages
[06:49] <BV1AL> but right after "Uncompressing linux... done, booting the kernel" it has no any response
[06:49] <scientes> ahh then its a bug in ubuntu
[06:50] <scientes> or in the parameters you are passing to the kernel
[06:50] <scientes> shoudl pass something like console=ttyS0,11520
[06:50] <BV1AL> when I type printenv, it has this console=xxxx
[06:50] <scientes> thats wrong
[06:51] <scientes> needs to be the above
[06:51] <scientes> but its "bootargs" that is the important variable
[06:51] <BV1AL> no, I mean it has the console=tty(something,speed
[06:51] <scientes> you have to study how it is booting before messing around
[06:51] <scientes> oh
[06:51] <scientes> well it might be good, and it might not
[06:51] <scientes> cause it has to pass it to the kernel too
[06:52] <scientes> via the bootargs variable in uboot
[06:52] <BV1AL> ok I'll try later
[06:53] <BV1AL> does this mean even I can login through serial port and configure, I still cannot use external keyb/mouse ?
[06:54] <scientes> serial port is with an external input
[06:54] <scientes> that is why serial is the universal debug port, its the simplest
[06:56] <BV1AL> but if everything need to send through serial port, this mean I have to depend on another PC
[06:57] <BV1AL> I wish to run Ubuntu on Blaze not debug
[06:57] <scientes> of course
[06:57] <scientes> but you need to run evtest to figure out what is going on with the keyboard/mouse
[06:57] <scientes> and dmesg
[06:58] <BV1AL> I see, thanks
[07:06] <BV1AL> the OTG port under ICS can act either master/slave mode depend on the microUSB I plugin
[07:08] <BV1AL> I wonder how to configure Ubuntu to let OTG port do exactly the same as ICS did ?
[07:09] <BV1AL> there are some demo on Youtube that they running Ubuntu on TI Blaze, how did they setup the external keyb/mouse ?
[07:11] <BV1AL> or the Ubuntu they do demo on Youtube different with the image they release for people to download ?
[07:13] <scientes> you need the usb port to be in host mode
[07:14] <BV1AL> I knew, so I plug in a microUSB with pin4-pin5 connected, this make it act as host
[07:14] <BV1AL> and this work as expected under ICS
[07:15] <scientes> well you need that serial port so you can read the kernel log
[07:15] <scientes> and then start sending in patches
[07:16] <scientes> when you fix it
[07:18] <BV1AL> is it possible to get the Ubuntu image some people demo successfully on TI Blaze ?
[07:18] <BV1AL> I think they did fixed it, otherwise hwo do they demo ?
[07:19] <scientes> i know nothing about that hardware
[07:19] <scientes> you have a page on the stats?
[07:20] <BV1AL> http://www.omappedia.org/wiki/OMAP4_Blaze
[07:21] <scientes> ooo thats pretty
[07:23] <LetoThe2nd> scientes: its TI's super-expensive omap4 dev platform
[07:24] <suihkulokki> fsov "super-expensive"
[07:24] <LetoThe2nd> ?
[07:26] <suihkulokki> if you actually are going to make an omap4 product, a blaze will be rounding error in the whole budget...
[07:26] <LetoThe2nd> sure, if you are into the omap4 production market thats totally irrelevant
[07:28] <LetoThe2nd> but there are those folks who want to just tinker around a bit on the omap, and compared to the panda its justified to call it expensive.
[07:30] <suihkulokki> well blaze isn't targeted for tinkerers
[07:31] <LetoThe2nd> i never said it was. i just called it expensive. :)
[08:09] <ogra_> blaze is a dual screen elephant cellphone ... only buy it if you also have the elephant to use it :P
[08:10] <phh> :)
[08:10] <phh> i didn't remember it could phone
[08:10] <ogra_> it has a SIM slot
[08:11] <LetoThe2nd> ogra_: not a SOM slit?
[08:11] <ogra_> not sure we ever had a driver ...
[08:12] <phh> but yeah, the blaze is here only for people who uses omap4 to complain to TI "see, it doesn't work for you either !"
[08:13] <ogra_> heh
[08:13] <phh> (yup that's from experience.)
[08:14] <ogra_> well, it was available before the panda at least  ... without blazes the ubuntu port would have been a release later
[14:50] <ogra_> infinity, any opinion ? http://paste.ubuntu.com/1113920/
[14:57] <infinity> ogra_: .d is a misleading name for that directory.
[14:57] <ogra_> just /etc/flash-kernel/bootscript/ then ?
[14:57] <infinity> ogra_: One expects .d directories to be full of snippets that get reconstructed.
[14:57] <ogra_> k
[14:58] <infinity> ogra_: Yeah, just mirroring the layout in /usr/share with bootscript/ seems sane.
[14:58] <infinity> (Though, I wouldn't be against designing a .d system where one could drop in bits, it's probably overkill)
[14:59] <ogra_> my next step would be to make f-k-i cp the input file from /usr/share/flash-kernel/bootscript/ and make f-k check for its existence
[14:59] <infinity> Well, you just made f-k look for it.
[14:59] <ogra_> and after that we should look into setting root= from f-k-i so we arent depending on initrd's
[15:00] <infinity> Also, this doesn't necessarily need to be a directory in /etc at all.
[15:00] <infinity> Why break past assumptions?
[15:00] <infinity> Can't we just use /boot/$usname ?
[15:00] <ogra_> you mean reading /boot/boot.script ?
[15:00] <ogra_> no
[15:00] <ogra_> $usname differs from boot.script
[15:01] <ogra_> it carries the subarch name
[15:01] <infinity> Ahh, so it does.  But that's fine.
[15:01] <infinity> It's still where people expected it to live.
[15:01] <infinity> And it's not a conffile.
[15:01] <ogra_> sure, but if we abuse /boot for configs again i would like to have backwards compatibility
[15:01] <infinity> *shrug*
[15:02] <ogra_> f-k-i should copy it from /usr/share/flash-kernel/bootscript/ to /boot/boot.script then
[15:02] <infinity> It's probably more correct to have it in /etc anyway.
[15:02] <ogra_> adn f-k should respect that
[15:02] <ogra_> why ? /etc is for configs or did that change
[15:02] <infinity> I was just thinking about people's assumptions, not about backward compat, per se.
[15:02] <ogra_> i was always shouted at for putting it into /boot
[15:02] <infinity> 09:02 < infinity> It's probably more correct to have it in /etc anyway.
[15:02] <infinity> ^-- I just said that. :P
[15:03] <ogra_> (though i still think its the most logical place)
[15:03] <infinity> Anyhow, drop the .d from that patch, and it seems sane enough to me.
[15:04] <ogra_> oh. sorry, misread more as not ...
[15:04]  * ogra_ is melting, germany has a heatwave
[15:04] <ogra_> ok
[15:04] <infinity> Or maybe even just /etc/flash-kernel/$whatever
[15:04] <infinity> There's nothing else being shipped in that directory, seems weird to have an empty directory just to contain another one.
[15:05] <ogra_> yea, less typing ... i wasnt sure we wouldnt have other stuff in there in the future
[15:05] <infinity> Even if we do, the bootscr.platform stuff is well-named.
[15:05] <infinity> And it's not like you'll have 30 of them.
[15:05] <infinity> Not in /etc anyway.
[15:05] <ogra_> and i would like to prevent having to migrate configs around more than i have to for release upgrades
[15:05] <infinity> Since you should really only have the one for the platform you're running.
[15:06] <ogra_> ok, i'll cut it
[15:35] <ogra_> infinity, so steve just convinced me to use /etc/default/flash-kernel and there only stote the additional cmdline options ... and them make f-k append these on boot.scr generation
[15:36] <infinity> That works too.
[15:36] <infinity> I'm not picky.
[15:36] <ogra_> sure. just a bit more work
[15:36] <infinity> Though, I thought there was a drive in Debian to deprecate /etc/default in general for wheezy+1
[15:37] <ogra_> that way we have an easy place to set root= too
[15:37] <ogra_> in favour of ?
[15:37] <infinity> Just making it go away.  Not necessarily replacing it with anything. :P
[15:38] <ogra_> heh
[15:38] <ogra_> that doesnt sound well thought through
[15:44] <ogra_> rsalveti, any PVR news ?
[15:45] <rsalveti> ogra_: I just tested with latest compiz + precise unity and things seems to be working nicely
[15:45] <ogra_> YAY, one positive thing at least
[15:46] <rsalveti> there's still an annoying bug but at least it's not dumping anything at the sgx side
[15:46] <ogra_> (seems compiz is still not ready)
[15:46] <rsalveti> not yet, I'm using the branch people are still working on
[15:46] <rsalveti> but I must say I'm quite happy with the results
[15:46] <rsalveti> people are finally merging the stuff back
[15:46] <rsalveti> and fixing a few other issues as well
[15:46] <rsalveti> so I'll be working at getting the driver at ubuntu in a few, now that the linaro release is done
[15:46] <ogra_> well, as long asd it lands in the ubuntu packages i will be happy too :)
[15:47] <rsalveti> yeah, probably before feature freeze I'd say
[15:47] <ogra_> but compiz is pretty closely bound to feature freeze
[15:47] <ogra_> yeah
[15:47] <rsalveti> yup
[15:48] <infinity> Is this all still build-time selection, or have we moved on to runtime yet?
[15:48] <ogra_> compiz you mean ?
[15:48] <ogra_> that should be runtime since GLES is also available on some intel chips nowadays
[15:48] <infinity> The GL/EGL stuff in compiz, nux, and unity.
[15:48] <infinity> Yes, it *should* be runtime selected, but it wasn't in precise. :P
[15:48] <infinity> Hence the question.
[15:49] <ogra_> but i dont know how much the reality matches "should"  :P
[15:49] <ogra_> i know it was disxcussed that way at UDS
[15:49] <rsalveti> hm, not that sure if this will land (runtime selection) at quantal
[15:50] <rsalveti> first thing I want to see is the code merged
[15:50] <ogra_> ++
[15:50] <rsalveti> and not maintaining that huge patch set anymore
[15:50] <rsalveti> after that we can discuss new features ;-)
[15:50] <ogra_> ++++++++ !
[15:51] <infinity> Fair enough.  Just as long as runtime selection is on someone's radar.
[15:52] <infinity> Right now, it matters for x86.  In the future, I bet it'll matter for some ARM platforms that decide to flip-flop back to pure GL.
[15:52] <ogra_> yup
[15:52] <infinity> (And we really need to sort out the QT GL/EGL thing sometime too, for similar reasons)
[15:52] <rsalveti> yup
[15:52] <infinity> Having that all build-time selected, and having to patch everything that links to QT is such a joke.
[15:53] <rsalveti> well, someone at Qt decided it was a good idea to let applications to render GL directly
[15:53] <rsalveti> while also using a GL-enabled Qt :-)
[15:53] <infinity> Well, you can't really stop people from using libGL directly.
[15:54] <rsalveti> which let people to do whatever they wanted
[15:54] <infinity> It's a shame that QT doesn't appear to provide a rich enough API that people feel they need to do so, though.
[15:54] <ogra_> sure you can.  make it a symlink tolibGLES
[15:54] <rsalveti> don't know how it's not working with qt5, but I'd expect to be similar in some way