| 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:36 |
| 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:37 |
| scientes | BV1AL, AFAIK OTG ports are reverse ports | 06:39 |
| scientes | so they don't work for what you want | 06:39 |
| 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:42 |
| 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:43 |
| BV1AL | serial port has no any response either | 06:44 |
| BV1AL | the monitor waiting me to select language for the system, but I can do nothing | 06:45 |
| scientes | did you unplug and replug in the keyboard? | 06:46 |
| BV1AL | yes I did | 06:47 |
| scientes | did you try with no hub? | 06:47 |
| scientes | anyways serial port is your best bet | 06:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| scientes | via the bootargs variable in uboot | 06:52 |
| BV1AL | ok I'll try later | 06:52 |
| BV1AL | does this mean even I can login through serial port and configure, I still cannot use external keyb/mouse ? | 06:53 |
| scientes | serial port is with an external input | 06:54 |
| scientes | that is why serial is the universal debug port, its the simplest | 06:54 |
| BV1AL | but if everything need to send through serial port, this mean I have to depend on another PC | 06:56 |
| 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:57 |
| BV1AL | I see, thanks | 06:58 |
| BV1AL | the OTG port under ICS can act either master/slave mode depend on the microUSB I plugin | 07:06 |
| BV1AL | I wonder how to configure Ubuntu to let OTG port do exactly the same as ICS did ? | 07:08 |
| BV1AL | there are some demo on Youtube that they running Ubuntu on TI Blaze, how did they setup the external keyb/mouse ? | 07:09 |
| BV1AL | or the Ubuntu they do demo on Youtube different with the image they release for people to download ? | 07:11 |
| scientes | you need the usb port to be in host mode | 07:13 |
| 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:14 |
| scientes | well you need that serial port so you can read the kernel log | 07:15 |
| scientes | and then start sending in patches | 07:15 |
| scientes | when you fix it | 07:16 |
| 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:18 |
| scientes | i know nothing about that hardware | 07:19 |
| scientes | you have a page on the stats? | 07:19 |
| BV1AL | http://www.omappedia.org/wiki/OMAP4_Blaze | 07:20 |
| scientes | ooo thats pretty | 07:21 |
| LetoThe2nd | scientes: its TI's super-expensive omap4 dev platform | 07:23 |
| suihkulokki | fsov "super-expensive" | 07:24 |
| LetoThe2nd | ? | 07:24 |
| 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:26 |
| 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:28 |
| suihkulokki | well blaze isn't targeted for tinkerers | 07:30 |
| LetoThe2nd | i never said it was. i just called it expensive. :) | 07:31 |
| ogra_ | blaze is a dual screen elephant cellphone ... only buy it if you also have the elephant to use it :P | 08:09 |
| phh | :) | 08:10 |
| phh | i didn't remember it could phone | 08:10 |
| ogra_ | it has a SIM slot | 08:10 |
| LetoThe2nd | ogra_: not a SOM slit? | 08:11 |
| ogra_ | not sure we ever had a driver ... | 08:11 |
| 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:12 |
| ogra_ | heh | 08:13 |
| phh | (yup that's from experience.) | 08:13 |
| ogra_ | well, it was available before the panda at least ... without blazes the ubuntu port would have been a release later | 08:14 |
| ogra_ | infinity, any opinion ? http://paste.ubuntu.com/1113920/ | 14:50 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| ogra_ | ok, i'll cut it | 15:06 |
| === TRON is now known as TypoNAM | ||
| 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:35 |
| 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:36 |
| 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:37 |
| ogra_ | heh | 15:38 |
| ogra_ | that doesnt sound well thought through | 15:38 |
| ogra_ | rsalveti, any PVR news ? | 15:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| infinity | Fair enough. Just as long as runtime selection is on someone's radar. | 15:51 |
| 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:52 |
| 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:53 |
| 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 | 15:54 |
| === zyga is now known as zyga-afk | ||
| === TRON is now known as TypoNAM | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!